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ABSTRACT 


The  project  budget,  schedule,  and  manpower  management  practices  currently 
used  within  the  Naval  Air  Systems  Command  (NAVAIR)  rely  heavily  on  manual  data 
extraction  and  processing,  which  is  perceived  to  be  inefficient  in  both  time  and  cost.  The 
purpose  of  this  systems  engineering  project  was  to  design  a  web-based  system  that 
collects,  collates,  and  formats  financial,  schedule,  and  status  information  for  multiple 
projects,  making  it  easier  and  quicker  for  different  levels  of  management  to  access  project 
information  and  make  decisions.  The  proposed  software  system  is  referred  to  as  the 
Competency  Administration  Toolset  (CAT). 

To  design  CAT,  the  team  followed  a  modified  version  of  the  Unified  Process  life 
cycle.  By  following  this  process,  the  team  was  able  to  work  frequently  with  stakeholders 
to  define  system  requirements  and  receive  feedback.  The  products  of  this  analysis 
included  an  interactive  proof-of-concept  graphical  user  interface  (GUI)  and  multiple 
systems  engineering  artifacts,  including  user  stories,  use  cases,  requirements 
documentation,  and  a  functional  architecture.  The  project’s  stakeholders  approved  the 
final  versions  of  these  products.  It  is  envisioned  that  the  stakeholders’  software 
development  teams  will  use  the  design  artifacts  to  fully  develop  and  operationally  deploy 
the  CAT  system  at  a  later  date. 
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EXECUTIVE  SUMMARY 


Many  of  the  current  methods  utilized  within  the  Naval  Air  Systems  Command 
(NAVAIR)  for  estimating  project  budget,  personnel  allocation,  and  scheduling  data  result 
in  inaccurate  estimates  for  decision  making.  Most  methods  rely  heavily  on  manual  data 
extraction  and  processing,  which  can  be  inefficient  in  both  time  and  cost.  One  NAVAIR 
competency  recognized  these  constraints  and  expressed  the  need  for  a  new  information 
technology  (IT)  system  that  provides  a  consistent  and  accurate  method  of  gathering  and 
viewing  project-related  financial,  schedule,  and  labor  metrics.  The  purpose  of  the  systems 
engineering  (SE)  project  described  in  this  report  was  to  design  a  web-based  system  that 
collects,  collates,  and  formats  project  financial,  schedule,  and  status  information  for 
multiple  projects,  reducing  the  level  of  effort  required  for  management  personnel  to 
access  project  information  and  make  decisions.  The  final  web-based  system  prototype 
created  for  this  project  is  referred  to  as  the  Competency  Administration  Toolset  (CAT). 

To  begin  the  design  process,  the  SE  team  had  in-depth  discussions  with  the 
competency  stakeholders  to  define  the  problem  space  of  the  current  system,  as  well  as  to 
define  the  requirements  for  the  new  system.  One  primary  requirement  emphasized  by  the 
stakeholders  was  that  the  new  software  system  be  web-based.  Knowing  this,  the  team 
determined  that  the  best  SE  approach  was  the  Unified  Process  (UP),  which  is  an  iterative 
process  developed  for  software  engineering  that  allows  stakeholders  to  provide  frequent 
feedback  to  the  system  design.  With  UP  allowing  for  an  iterative  approach  to  obtain  and 
integrate  feedback,  Team  CAT  deemed  this  process  to  be  a  more  suitable  choice, 
compared  to  the  traditional  “waterfall'’  processes.  Team  CAT  modified  the  UP  approach 
to  better  suit  the  needs  of  this  project;  however,  the  concept  of  iterative  development 
remained  a  focus  of  the  design  process. 

One  of  the  biggest  challenges  for  Team  CAT  was  to  ensure  that  the  authoritative 
source  data  pulled  from  multiple  sources,  specifically  the  Navy  Enterprise  Resource 
Planning  (NERP)  and  Command  Staffing  databases,  was  accurately  pulled,  stored,  and 
processed.  To  ensure  the  pulled  data  fulfilled  stakeholders’  needs,  Team  CAT  focused  on 

developing  unambiguous  SE  artifacts  from  the  start.  The  team  identified  stakeholders’ 

xvii 


requirements,  then  mapped  the  flow  of  data  and  functionality  within  the  system.  After 
conducting  additional  stakeholder  interviews,  the  team  was  able  to  develop  the  necessary 
artifacts,  which  included  user  stories,  use  cases,  requirements,  and  a  functional 
architecture  composed  of  action  diagrams.  The  collaborative  model -based  systems 
engineering  (MBSE)  toolset  used  to  develop  these  artifacts  was  “Innoslate.” 

Another  challenge  for  Team  CAT  was  to  determine  how  to  display  the  data  of 
interest  for  multiple  stakeholders,  each  with  his  or  her  own  priorities  and  preferences,  in  a 
way  that  was  intuitive  and  user-friendly.  The  team  decided  the  best  approach  was  for 
CAT  to  have  separate,  customized  dashboard  displays  for  each  user  type,  based  on  the 
role  within  the  NAVAIR  competency.  The  team  developed  several  iterative  prototypes  of 
these  dashboards,  each  with  increased  detail  and  complexity.  The  dashboards  began  as 
wireframe  models  drawn  on  paper,  to  general  dashboard  arrangements  using  Microsoft 
PowerPoint,  and  then  progressed  to  a  detailed  website  with  interactive  interfaces  using 
HTML  and  PHP.  Each  dashboard  version  received  feedback  from  stakeholders  regarding 
preferences  for  how  the  information  should  be  organized  and  displayed.  The  iterative 
design  improvements  continued  until  the  stakeholders  agreed  on  a  final  version  of  the 
dashboards. 

The  result  was  an  interactive,  comprehensive  graphical  user  interface  (GUI) 
layout,  validated  by  all  stakeholder  groups.  These  stakeholders  also  reviewed  and 
approved  all  SE  artifacts  necessary  for  eventual  system  development.  With  the 
development  groundwork  successfully  established  by  Team  CAT,  the  competency’s 
software  development  team  will  be  able  to  align  the  desired  user  experience,  represented 
by  the  prototype  GUI,  with  the  user  functionality  needs  captured  in  the  SE  artifacts. 


I. 


INTRODUCTION 


A  Naval  Air  Systems  Command  (NAVAIR)  competency  has  expressed  the  need 
for  a  new  information  technology  (IT)  system  that  provides  a  consistent  and  accurate 
method  of  gathering  and  viewing  project-related  financial,  schedule,  and  labor  metrics. 
Such  a  system  would  provide  a  more  informed  decision-making  process  for  project 
managers  and  competency  leadership.  The  project  described  in  this  report  focuses  on 
developing  systems  engineering  (SE)  artifacts  to  design  a  prototype  system  that  satisfies 
these  needs.  This  system  is  named  the  Competency  Administration  Toolset  (CAT),  with 
project  members  referred  to  as  “Team  CAT.”  The  focus  of  Chapter  I  is  to  discuss  the 
problem  areas  that  generated  the  need  for  this  project,  highlight  the  project’s  goals  and 
scope,  and  describe  the  technical  approach  used  to  design  the  system. 

A.  PROBLEM  STATEMENT 

The  project  management  practices  implemented  by  the  stakeholders  did  not 
provide  project  management  information  to  the  competency  with  sufficient  speed, 
consistency,  or  accuracy  for  satisfactory  management  decision  making.  In  the  context  of 
this  report,  the  term  “competency”  refers  to  a  department  that  represents  a  specific 
functional  area  of  expertise  within  NAVAIR.  Due  to  the  heavy  dependence  on  manual 
data  input,  the  competency’s  current  project  management  system  suffers  from  several 
significant  shortcomings,  including  long  lead  times  to  obtain  project-specific  data,  non- 
stanclardized  methods  of  document  generation,  and  manual  creation  of  charts  for  metrics 
communication.  All  of  these  inefficiencies  ultimately  result  in  a  lack  of  confidence  in 
data  accuracy. 

Discussion  with  stakeholders  made  clear  that  the  current  process  for  collecting, 
processing,  and  disseminating  data  remains  a  manual  process  because  the  data  sources 
and  databases  are  in  multiple,  disparate  formats,  which  are  neither  readily  compatible 
with  each  other,  nor  well  integrated.  The  stakeholder  competency’s  Budget  Financial 
Managers  (BFMs)  used  two  independent  data  repositories,  including  Navy  Enterprise 
Resource  Planning  (NERP)  and  the  Command  Staffing  Tool,  to  obtain  project  funding 
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and  competency  manning  data.  NERP  is  the  Department  of  the  Navy  (DON)  financial 
system  of  record,  meaning  it  provides  reliable  information  for  Navy  leadership  to  keep 
moving  forward  (U.S.  Navy  2017).  The  Command  Staffing  Tool  solicits  all  planned  work 
and  apportions  NAVAIR  competency  personnel  to  execute  program  offices’  acquisition 
plans  (Department  of  the  Navy,  Naval  Inspector  General  2012).  Access  to  these  databases 
is  controlled  by  Big-IP,  which  helps  validate  user  credentials  in  accordance  with 
Department  of  Defense  (DOD)  security  requirements  (F5  Networks  2017). 

The  competency’s  BFMs  use  data  from  the  two  aforementioned  databases  to 
create  spreadsheets  for  tracking  and  managing  projects’  funding  details,  including 
projects’  account  charging  numbers  known  as  “chargeable  object  numbers”  (CONs), 
technical  points  of  contact  (TPOCs),  as  well  as  the  amount  and  type  of  funds  remaining 
for  each  project.  When  requested  by  competency  leadership,  the  BFMs  also  create  graphs 
and  charts  from  these  metrics.  However,  the  data  presented  to  competency  leadership  and 
decision  makers  is  often  outdated  and  inaccurate,  due  to  infrequent  source  data  refreshes 
combined  with  long  lead  times  in  the  manually  intensive  process  of  collecting, 
processing,  and  disseminating  the  data. 

An  additional  problem  with  the  original  system  derives  from  the  lack  of  a  uniform 
method  to  format  and  present  project  data.  Within  the  competency,  each  branch  head 
supervises  multiple  project  managers,  each  of  whom  has  his  or  her  own  methods  to  track 
projects’  funding,  schedule,  and  status  data.  Prior  to  reporting  up  the  chain  of  command 
to  senior  leadership,  branch  heads  are  required  to  reformat,  standardize,  and  recompile 
the  project  managers’  data.  According  to  the  stakeholders,  the  inefficient  processes  and 
rework  cost  valuable  time  that  otherwise  could  have  been  invested  in  more  productive 
tasks. 

B.  STAKEHOLDERS 

There  were  several  groups  within  the  NAVAIR  competency  who  had  a  stake  in 
how  CAT  was  designed,  including  the  Budget  Financial  Managers  (BFMs),  the  Project 
Managers  (PMs),  the  Branch  Heads  (BHs),  and  Senior  Feadership  (SF).  Each  group 
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represented  a  different  management  level,  with  differences  in  technical  expertise, 
priorities,  and  level-of-detail  involvement. 

BFMs  perform  specific  financial-management  tasking  for  all  competency  projects 
and  support  the  data  needs  for  the  competency.  Each  project  in  the  competency  is 
assigned  a  PM  who  oversees  and  tracks  the  technical  execution  and  finances  of  the 
project.  Correspondingly,  BHs  manage  the  work  performed  by  the  PMs,  and  BHs  are 
managed  by  the  competency’s  SL.  The  term  “SL”  is  a  broad  category  that  includes  the 
division  heads  who  manage  the  long-term  goals  of  divisions  in  the  competency,  as  well 
as  competency  technical,  military,  and  operations  directors.  Team  CAT  decided  to 
combine  these  multiple  types  of  upper-management  within  one  SL  group,  since  all  roles 
receive  similar  data  from  the  lower  levels  of  competency  management.  Chapter  II, 
Section  B  provides  additional  details  on  the  definition  and  roles  of  each  stakeholder 
group. 


C.  GOALS  AND  OBJECTIVES 

The  goals  of  this  project  were  to  (i)  design  a  project  management  system  to  track 
and  manage  the  cost,  schedule,  and  status  of  the  stakeholder  competency’s  unclassified 
projects,  (ii)  develop  a  system  architecture  to  trace  stakeholder  needs  down  to  specific 
system  functionality,  and  (iii)  develop  a  prototype  as  a  proof  of  concept  for  the  system 
functionality  and  user  interface.  Development  of  the  actual  CAT  system  was  not  a  goal 
for  this  project.  The  focus  was  solely  on  designing  the  unambiguous  system  engineering 
artifacts  to  support  the  eventual  development  and  deployment  of  CAT  by  the 
competency’s  software  development  team. 

At  the  start  of  the  analysis  for  the  system  design,  the  stakeholders  emphasized  the 
high-level  objectives  for  the  CAT  system.  After  eliciting  stakeholder  needs,  it  was 
determined  that  the  CAT  system  should  be  able  to: 

1.  Provide  a  Navy  Marine  Corps  Intranet  (NMCI)  compatible,  web-based 
graphical  user  interface  (GUI). 

2.  Track  and  report  key  project  schedule  items. 

3.  Track  and  report  project  funding  levels  and  expenditure  rates. 
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4.  Track  and  report  project  status. 

5.  Track  and  report  projects’  personnel  usage  and  allocation. 

The  CAT-generated  reports  would  include  project  details  such  as  progress  on 
deliverables  and  funding  status.  Ideally,  when  developed,  CAT  will  create  these  up-to- 
date  reports  on-demand,  using  the  most  updated  source  data.  The  stakeholder  competency 
also  suggested  that,  once  this  system  has  proven  successful  at  the  competency  level,  CAT 
has  the  potential  to  grow,  adapt,  and  expand  to  serve  other  NAVAIR  competencies  and 
improve  the  command’s  overall  project  management  processes. 

D.  PROJECT  SCOPE 

When  the  stakeholders  first  approached  the  SE  team  to  develop  the  CAT  system, 
they  provided  a  detailed  list  of  desired  capabilities  and  functions.  However,  due  to  the 
restricted  timeline  and  resources  available  to  Team  CAT,  it  was  important  to  prioritize 
the  capabilities  and  establish  a  scope  that  was  realistically  achievable  for  the  project. 

Figure  1  illustrates  the  envisioned  scope  of  how  CAT  would  fit  into  the 
stakeholders’  current  project  management  processes,  the  different  databases  that  CAT 
would  obtain  data  from,  as  well  as  the  users  that  would  interact  with  the  CAT  system. 
The  context  diagram  in  Figure  1  was  used  to  (i)  communicate  expectations  on  scope  with 
stakeholders,  (ii)  document  the  types  of  data  that  will  be  required  to  import/export  for/ 
from  the  system,  and  (iii)  specify  the  types  of  interactions  stakeholders  could  expect  with 
the  system.  It  also  served  as  the  foundation  for  all  follow-on  discussions  and  SE  artifacts 
that  Team  CAT  created  during  the  system  design  process. 
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Figure  1 .  CAT  Context  Diagram 

Through  discussion  with  the  stakeholders,  it  was  determined  that  the  scope  of  this 
project  focused  on  providing  the  stakeholders  with  the  following  deliverables: 

1.  List  of  stakeholders’  needs  represented  as  user  stories 

2.  List  of  operational-level  use  cases 

3.  Architectural  artifacts  to  define  and  establish  the  system’s  functional  and  data 
flows 

4.  An  interactive,  prototype  GUI  based  on  stakeholder  inputs  and  human  systems 
integration  (HSI)  best  practices  to  demonstrate  how  users  can  expect  to 
interact  with  the  system.  This  GUI  was  meant  to  be  a  prototype  of  the  system 

The  team  determined  that  other  tasking,  additional  iterations,  and  further  system 
improvements  were  outside  the  limited  scope  of  this  project.  The  scope  included 
designing  the  SE  artifacts  and  an  interactive  GUI  prototype,  so  that  a  future  software 
development  team  could  take  over  the  actual  development  and  deployment  of  the  system. 
It  is  intended  that,  once  developed  and  deployed,  the  use  of  CAT  will  enable  competency 
leadership  to  access  the  most  updated  project  information,  such  as  project  funding  levels, 
project  status,  or  personnel  project  support  levels.  CAT  will  also  generate  uniformly 
formatted  graphs  and  visuals,  providing  a  consistent  reporting  process. 
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E.  ASSUMPTIONS  AND  CONSTRAINTS 


The  primary  constraint  for  CAT  was  the  stakeholder’s  request  for  a  web-basecl 
toolset  as  part  of  the  materiel  solution.  By  conducting  doctrine,  organization,  training, 
materiel,  leadership  and  education,  personnel,  facilities  and  policy  (DOTMLPF-P) 
analyses,  alternatives  other  than  CAT  could  have  been  considered  as  solutions  to  the 
problem;  however,  the  customer  insisted  on  the  use  of  a  web-based  materiel  solution.  As 
a  result.  Team  CAT  assumed  the  request  for  a  material  solution  to  be  valid  and  did  not 
conduct  an  analysis  of  alternatives. 

As  a  result  of  the  CAT  system  having  to  be  web-based  and  capable  of  handling 
for  official  use  only  (FOUO)  information,  the  CAT  system  needed  to  be  compatible  with 
the  NMCI  network,  including  all  corresponding  firewall  and  cybersecurity  requirements. 
Team  CAT  created  the  system  design  with  the  assumption  that,  during  future 
development  and  deployment  of  CAT,  the  competency’s  software  programming  team 
would  have  the  ability  to  establish  all  required  live  connections  to  external  databases  and 
corresponding  security  measures,  as  they  have  done  for  other  projects  within  the 
competency.  Additionally,  Team  CAT  designed  alternate  methods  of  transferring  data 
into  CAT,  in  the  event  that  these  live  connections  were  not  immediately  available. 
Appendix  A  provides  a  more  detailed  discussion  of  what  Team  CAT  recommends  as  a 
deployment  strategy,  including  what  to  consider  when  obtaining  live  connections  to 
external  databases.  However,  in  general,  deployment  of  the  system  itself  was  outside  the 
scope  of  this  project. 

F.  TECHNICAL  APPROACH  -  THE  UNIFIED  PROCESS 

Team  CAT  designed  the  CAT  system  by  following  the  technical  approach  known 
as  the  Unified  Process  (UP)  (Pressman  and  Maxim  2015,  55).  This  approach  was  used  so 
that  the  team  could  iteratively  deliver  SE  artifacts  and  prototype  GUIs  to  stakeholders, 
elicit  detailed  feedback,  and  then  immediately  use  that  feedback  to  improve  the  artifacts 
and  prototypes.  The  iterative  nature  of  this  process  reflects  the  core  philosophy  and 
principles  of  the  UP,  which  is  defined  as  “use  case  driven,  architecture-centric,  iterative 
and  incremental”  process  (Pressman  and  Maxim  2015,  53).  Using  UP,  versions  of 
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products  are  delivered  incrementally  over  time;  rather  than  one  final  product  at  the  end  of 
the  project  as  seen  with  the  waterfall  approach. 

Team  CAT  believed  that  the  most  important  way  for  this  project  to  remain  valid 
(i.e.,  satisfy  stakeholder  needs)  was  by  frequently  including  customer  communication  in 
the  design  process.  By  following  the  UP,  Team  CAT  successfully  included  frequent 
customer  inputs  regarding  the  design  of  the  SE  artifacts.  The  following  sections  provide  a 
brief  explanation  of  the  traditional  UP,  the  modified  process  followed  by  Team  CAT,  and 
how  the  team  created  and  updated  SE  artifacts  in  a  specific  order  related  to  the  modified 
UP. 


1.  Traditional  Unified  Process 

As  displayed  in  Figure  2,  the  traditional  UP  has  “phase”  and  “activity” 
components.  The  overarching  phases  correspond  to  the  broad  goals  of  the  project,  while 
the  activities  represented  in  the  boxes  correspond  to  specific  actions  that  are  performed 
iteratively  throughout  the  project.  The  phases  and  activities  are  repeated  iteratively 
together;  however,  the  transitions  between  phases  do  not  directly  correlate  with  the 
transition  of  activities. 


Elaboration 


Production 


Figure  2.  The  Unified  Process.  Source:  Pressman  and  Maxim  (2015,  57) 
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The  four  overarching  phases  of  the  UP  include  Inception,  Elaboration, 
Construction,  and  Transition  (Pressman  and  Maxim  2015).  The  UP  also  includes  a  fifth 
phase,  Production,  as  needed  (Ambler  2006).  The  Inception  phase  includes  the  initial 
communication  and  planning  activities  performed  for  each  iteration.  The  goal  of  the 
Inception  phase  is  to  identify  the  scope  of  work  to  perform,  identify  potential 
architectural  representations  for  the  system,  and  receive  initial  stakeholder  acceptance. 
The  Elaboration  phase  includes  additional  communication  activities,  combined  with 
initial  modeling  activities.  The  goal  of  the  Elaboration  phase  is  to  develop  and  verify  that 
the  system  architecture  meets  the  stakeholder  requirements.  The  Construction  phase 
includes  further  modeling,  construction,  and  testing  activities.  The  goal  of  the 
Construction  phase  is  to  build  a  working  product  that  meets  the  highest-priority  needs  of 
project  stakeholders.  The  Transition  phase  includes  the  latter  stages  of  both  modeling  and 
construction  activities,  with  the  goal  of  validating  the  final  system  for  that  version. 
Lastly,  the  Production  phase  includes  deployment  of  the  system’s  version  into  its  end-use 
environment.  In  some  references,  the  UP  includes  a  combined  Production  and  Transition 
phase  (Ambler  2006). 

2.  Modified  Unified  Process 

For  the  design  of  the  CAT,  the  team  placed  a  greater  emphasis  on  the  progression 
of  activities  performed  within  each  UP  phase,  rather  than  the  phases  themselves.  They 
performed  the  communication,  planning,  modeling,  and  construction  activities  in  the 
same  order  for  all  iterations  of  the  CAT  design  project. 

•  Communication  activities  included  working  with  stakeholders,  such  as  the 
competency’s  BFMSs,  PMs,  BHs,  and  SL,  to  define  and  refine  user  stories 
and  requirements,  as  well  as  to  propose  and  refine  the  architecture  views  of 
the  system.  These  activities  also  included  further  elaboration  and 
decomposition  of  the  system’s  functional  requirements.  By  communicating 
with  the  stakeholders  often,  Team  CAT  obtained  a  better  understanding  of  the 
underlying  problem  and  the  stakeholders’  requirements.  As  the  primary 
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customers  and  future  users  of  the  system,  these  stakeholders  held  crucial 
information  and  opinions  from  distinct  perspectives. 


•  Planning  activities  built  directly  upon  communication  activities.  These 
activities  primarily  consisted  of  drafting  or  refining  functional  decomposition 
models  and  other  SE  artifacts.  Planning  activities  also  included  analyzing 
interfaces  between  users,  analyzing  CAT’s  interfaces  to  external  systems, 
researching  human  system  integration  concerns,  and  refining  the  project 
schedule.  As  the  project  matured,  the  planning  activities  also  included  refining 
the  SE  artifacts  into  a  set  of  models  that  represented  the  stakeholder-requested 
architectural  views  of  the  system  (Pressman  and  Maxim  2015). 

•  Modeling  activities  included  using  the  black-box  models  created  in  the  earlier 
activities  to  create  white-box  system  models  represented  with  action  diagrams. 
The  action  diagrams  represented  both  data  and  functional  flow,  thereby 
replacing  traditional  data  flow  and  functional  flow  block  models  (Da  2013). 

•  Construction  activities  focused  on  the  development  and  refinement  of  the 
prototype  GUI.  Team  CAT  developed  the  first  version  of  the  prototype  using 
hand-drawn  wireframe  diagrams.  Then,  based  on  stakeholder  input,  the  team 
converted  the  wireframe  diagrams  to  a  Microsoft  PowerPoint  layout  to 
determine  how  to  arrange  elements  of  the  interface.  Finally,  the  team 
developed  a  web-based  prototype  GUI  using  HTML  and  PHP  scripting 
languages.  By  creating  the  web-based  prototype,  the  team  intended  to  provide 
more  detailed  user  interaction  to  elicit  more  focused  user  input  to  the  design. 
In  the  future,  the  stakeholder  competency’s  software  development  team  will 
use  the  final  GUI  prototype,  combined  with  the  other  SE  artifacts,  to  build  the 
actual  functioning  version  of  CAT. 

Figure  3  illustrates  and  summarizes  the  flow  of  activities  followed  for  both 
iterations  of  the  CAT  design  process.  Since  Team  CAT  focused  on  developing  the  system 
architecture  and  the  GUI  prototype,  they  did  not  perform  the  deployment  activity,  which 
is  traditionally  part  of  the  UP.  The  grayed-out  boxes  in  Figure  3  illustrate  the  activities 
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that  the  traditional  UP  usually  includes  (Figure  2),  but  that  the  team  did  not  include  for 
this  project. 


Figure  3.  Team  CAT’s  Modified  UP 


Team  CAT  focused  on  performing  two  iterations  of  the  modified  UP  for  this 
project.  After  the  completion  of  each  iteration,  Team  CAT  validated  the  SE  artifacts  they 
had  developed  by  holding  formal  in-process  reviews  (IPRs)  with  all  project  stakeholders. 
The  goals  of  conducting  IPRs  were  to  (i)  ensure  that  the  project  continued  to  adhere  to  all 
the  stakeholders’  needs  for  the  system  and  (ii)  elicit  new  design  direction  from  the 
stakeholders  by  presenting  the  SE  artifacts  and  prototypes.  In  this  way,  each  IPR  also 
aligned  with  the  project’s  progression  into  the  next  UP  iteration. 

3.  Logical  Progression  of  SE  Artifact  Development 

As  Team  CAT  received  input  from  the  users  and  stakeholders  during 
communication  activities,  they  refined  and  updated  the  SE  artifacts,  leading  to  the 
eventual  update  of  the  prototype  GUI.  Figure  4  illustrates  the  order  in  which  Team  CAT 
created  and  updated  these  SE  artifacts  during  both  iterations  of  the  modified  UP. 
Occasionally,  earlier  SE  artifacts  needed  to  be  updated  as  concepts  became  more  refined. 
For  example,  after  exploring  constraints  set  forth  by  interface  requirements,  Team  CAT 
modified  the  use  cases  so  that  all  artifacts  were  aligned  and  fully  traceable  to  each  other. 
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Note  that  each  SE  artifact  roughly  aligns  with  each  of  the  UP  activities  performed  during 
the  iterative  design  process. 


Functional  Architecture 


ACTION  DIAGRAMS 


V 


Construction 


Figure  4.  SE  Artifacts  Created  for  CAT  Design 


By  applying  the  UP  to  the  design  of  the  CAT  system,  Team  CAT  was  able  to 
coordinate  continuously  with  stakeholders  to  obtain  feedback,  which  resulted  in  the 
development  of  several  mature  SE  artifacts  and  a  prototype  GUI  that  met  stakeholder 


11 


needs.  In  the  future,  the  stakeholders’  software  development  team  will  be  able  to  use  the 
provided  SE  artifacts  and  prototype  GUI  to  develop  and  deploy  CAT. 

4.  Model-Based  Systems  Engineering  Tool  to  Create  SE  Artifacts 

Team  CAT  used  the  model-based  systems  engineering  (MBSE)  toolset  Innoslate 
as  the  central  repository  for  all  the  SE  artifacts  created  during  the  design  process. 
Innoslate  is  a  web-based  collaborative  MBSE  toolset  developed  by  Spec  Innovations  to 
serve  as  a  project’s  single  source  for  MBSE  analysis.  By  using  Innoslate,  Team  CAT  was 
able  to  document  the  traceability  between  use  cases,  user  stories,  requirements,  and 
functions.  Furthermore,  in  addition  to  using  Innoslate  for  traceability  purposes,  Team 
CAT  used  Innoslate  to  create  action  diagrams  to  represent  functional  flow  and  data 
transformation  through  the  system.  Appendix  B  contains  the  detailed  Life  Cycle 
Modeling  Language  (LML)  ontology  built  into  Innoslate,  which  was  used  by  the  team  for 
the  model’s  traceability  relationships. 

G.  REPORT  ROADMAP 

The  structure  of  this  report  reflects  the  flow  of  activities  as  they  occurred  during 
one  iteration  of  the  UP.  Rather  than  decomposing  the  report  into  two  iterations  and 
repetitively  describing  the  activities  as  they  occurred  in  each  separate  iteration,  each 
chapter  is  based  on  the  SE  artifacts  discussed  in  Section  F.3  of  Chapter  I. 

Chapter  II  describes  the  results  of  the  communication  and  planning  activities, 
including  the  definition  of  the  problem  space,  description  of  stakeholders,  definition  of 
user  stories,  and  development  of  use  cases.  Chapter  III  describes  the  derivation  and 
decomposition  of  the  CAT  requirements.  Chapter  IV  describes  the  functional  analysis 
using  architecture  views.  Chapter  V  describes  the  best  practices  followed  by  Team  CAT 
for  prototype  GUI  design,  as  well  as  the  progression  of  the  GUI  design.  Finally, 
Chapter  VI  summarizes  the  project  accomplishments  and  proposes  future  growth 
opportunities. 
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II.  PROBLEM  SPACE  EXPLORATION 


A.  BACKGROUND 

As  discussed  in  Chapter  I,  a  NAVAIR  competency  sponsored  this  project  to 
design  a  solution  to  the  issues  surrounding  the  current  project  management  process.  The 
competency  accepts  and  completes  many  small-scale  engineering  and  analysis  projects 
which  may  vary  in  length  from  a  couple  weeks  to  several  years.  The  number  of  personnel 
assigned  to  each  project  can  range  anywhere  from  one  person  per  project  to  multiple 
cross-domain  teams  per  project. 

One  of  the  main  problems  with  the  current  project  management  system  stems 
from  the  fact  that  each  level  of  management  requires  different  degrees  of  project  details 
to  review.  Additionally,  each  Budget  Financial  Manager  (BFM),  Project  Manager  (PM), 
Branch  Head  (BH),  and  Senior  Leadership  (SL)  has  his/her  own  preferences  and 
priorities  that  govern  the  presentation  and  display  of  project  data.  Currently,  to  work 
around  these  issues,  each  level  of  management  uses  valuable  time  to  consolidate  and 
reformat  all  information  received  from  subordinates.  There  is  no  standardized  method 
governing  document  generation  and  formatting.  Figure  5  illustrates  the  relative  degree  of 
detailed  project  knowledge  and  data  required  by  each  level  of  management. 


Less  Detailed^!  Senior  Leadership 

Data 

Branch  Heads 

Project  Managers 


A 


/lore  Detailed 
Data 


Branch  Heads 

Project  Managers 

Budget  Financial 
Managers 


Figure  5.  Relative  Level-of-Detail  Required  per  Level  of  Management 
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1.  Current  Management  Processes  in  the  Competency 

The  current  project  management  process  followed  by  the  NAVAIR  competency 
relies  heavily  on  the  data  collection,  processing,  and  dissemination  tasks  performed  by 
the  BFM.  Figure  6  provides  a  high-level  illustration  of  how  data  flows  from  source 
databases,  through  the  BFM,  to  the  competency  end  users. 


Figure  6.  Current  Competency  Management  Process  Context  Diagram 


The  following  sections  describe  the  processes  performed  by  each  stakeholder 
group,  as  part  of  the  competency’s  current  project  management  process.  Team  CAT 
obtained  this  information  by  conducting  informal  interviews  with  the  stakeholders. 
Appendix  C  includes  a  list  of  the  type  of  questions  asked  of  each  stakeholder  group.  The 
Naval  Postgraduate  School’s  (NPS)  Institutional  Review  Board  (IRB)  reviewed  these 
questions  and  approved  their  use. 

a.  Current  BFM  Processes 

The  BFMs  begin  by  downloading,  processing,  and  distributing  project  financial 
and  personnel  data,  some  of  which  is  individualized  to  fulfill  specific  requests  made  by 

14 


PMs,  BHs,  or  SL  stakeholders.  Downloading  the  source  data  involves  specifying  and 
retrieving  information  from  several  databases,  including  NERP  and  Command  Staffing. 
The  raw  data  is  downloaded  as  multiple  Microsoft  Excel  files  and  reformatted  using 
Visual  Basic  for  Application  (VBA)  macros.  The  time  required  to  download  and  reformat 
all  project  data  from  just  one  of  these  databases  takes  anywhere  from  two  to  three  hours. 
Furthermore,  due  to  the  inherent  structure  of  the  VBA  macros  and  processing  limitations 
on  the  BFMs’  computers,  the  BFMs  are  unable  to  perform  any  other  tasking  on  their 
computers  during  this  interval. 

Once  the  BFMs  obtain  project  data  from  the  source  databases,  they  convert  the 
information  into  Microsoft  Excel  workbooks.  Occasionally,  requests  necessitate 
generation  of  a  full  report  with  graphics.  For  example,  SF  stakeholders  have  been  known 
to  ask  for  the  breakdown  of  manning  levels  within  the  competency,  which  are  displayed 
using  bar  charts.  Figure  7  provides  an  example  of  what  the  manning  level  bar  charts 
typically  look  like.  Additional  SF  requests  can  include  a  breakdown  of  project  sponsors 
by  funding  amount,  as  well  as  a  breakdown  of  overhead  funding  levels  within  the 
competency.  The  amount  of  time  required  to  create  the  required  visuals  depends  on  the 
amount  of  detail  required  by  the  specific  requests  from  SF. 


Figure  7.  Example  of  Competency  Manning  Fevels  Chart 
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Regardless  of  individual  data  requests,  the  BFMs  routinely  develop  and  distribute 
a  Microsoft  Excel  Workbook  containing  all  projects’  funding  details.  This  is  done 
approximately  every  two  to  three  weeks  and  depends  upon  the  BFMs’  workload  as  well 
as  the  amount  of  change  that  has  occurred  in  the  data  since  the  previous  distribution.  The 
workbook  provides  the  funding  information  for  every  project  in  the  competency.  Due  to 
the  excessive  amount  of  manual  effort  required  to  accomplish  the  required  reformatting, 
the  process  can  take  up  to  a  week.  By  that  time,  the  information  provided  to  PMs,  BHs, 
or  SL  may  no  longer  be  accurate  or  useful  for  decision  making  purposes.  To  protect 
proprietary  data,  this  report  does  not  include  specific  data  from  the  workbook;  however, 
Appendix  D  provides  an  example  of  an  empty  funding  status  sheet,  commonly  referred  to 
as  a  “Longsheet.” 

b.  Current  Project  Manager  Processes 

PMs  require  insight  into  project  cost,  schedule,  and  status  to  oversee  projects 
competently.  Within  the  sponsoring  competency,  the  tracking  and  management  processes 
vary  amongst  the  PMs.  Through  interviews  with  PMs,  Team  CAT  determined  that  the 
most  common  method  used  to  track  cost  information  involves  a  combination  of  Microsoft 
Excel  spreadsheet  products,  Microsoft  Project,  and  the  BFM-provided  Longsheets. 

BHs  require  status  information  from  PMs  on  a  recurring  basis  to  maintain  insight 
into  projects’  status.  Team  CAT  determined  from  stakeholder  interviews  that  each  time 
BHs  send  out  a  request  for  updated  project  management  data,  PMs  have  to  specially 
prepare  and  refine  management  data  products.  Preparation  may  involve  organizing  or 
reorganizing  existing  data  products,  creating  PowerPoint  briefs,  or  extracting  and 
summarizing  points  of  interest  for  the  project.  This  process  is  always  manual,  causing  the 
PMs  to  spend  more  time  than  desired  to  keep  their  BH  informed,  rather  than  actively 
managing  their  projects  and  leading  project  personnel. 

c.  Current  Branch  Head  Processes 

The  BH  process  begins  by  consolidating  all  of  the  project  information  (typically 

quad  charts)  sent  by  the  individual  PMs  for  all  the  projects  in  the  branch.  The  BH  then 

performs  a  review  of  the  data,  ensuring  that  deliverables,  milestones,  project  statuses,  and 
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financial  spending  meet  the  branch’s  goals.  The  BH  also  reformats  the  information  from 
all  individual  PMs  to  prepare  for  forwarding  up  the  chain  of  command  to  SL 
stakeholders.  The  process  of  reformatting  this  data  is  time  consuming  and  requires  the 
BH  to  produce  data  visualization  products  for  SL  manually. 

In  addition,  the  BH  is  responsible  for  managing  how  to  assign  personnel  to  each 
of  the  branch’s  projects,  using  the  People  to  Project  tracker — a  spreadsheet  tool  that  maps 
each  employee  to  the  projects  that  he  or  she  supports.  Since  all  employees  within  the 
competency  charge  their  time  directly  to  the  project  accounts,  maintaining  this  tool 
eventually  translates  into  direct  funding  management  for  the  branch. 

Even  though  the  current  People  to  Project  tracker  is  the  primary  tool  to 
communicate  personnel  allocation  to  projects  in  the  competency,  the  tool  is  limited  in  its 
capabilities.  For  example,  there  is  currently  no  method  to  assign  personnel  to  a  project  for 
a  specified  period.  As  a  result,  it  is  difficult  for  BHs  to  determine  who  is  over-allocated, 
or  when  a  person  might  have  better  availability  in  the  year  for  additional  tasking.  There 
have  been  cases  of  employees’  project  assignments  totaling  more  than  one  work  year, 
which  results  in  perceived  over-tasking  for  the  year,  when  in  fact,  the  projects  may  run 
simultaneously  for  only  a  couple  months  of  the  year. 

Since  many  of  the  BHs  are  not  satisfied  with  the  current  capabilities  of  the  People 
to  Project  tracker,  they  will  also  often  have  alternate,  individual  tracking  methods,  such 
as  using  whiteboards,  Excel  spreadsheets,  or  just  notebooks,  to  manage  project 
assignments.  Despite  all  of  the  ways  in  which  BHs  try  to  manage  which  workers  are 
assigned  to  which  projects,  an  ideal  tool  or  method  that  provides  all  the  desired 
capabilities  is  not  currently  available. 

d.  Current  Senior  Leadership  Processes 

As  mentioned  in  Chapter  II,  Section  A.l.c.,  BHs  consolidate  PMs’  status  inputs 
into  summaries  for  SL,  which  are  usually  in  Microsoft  Word  format.  Any  supporting  data 
visualizations  are  often  custom-made  and  prepared  in  either  Microsoft  PowerPoint  or 
Microsoft  Excel  format.  On  a  weekly  basis,  all  updates  for  every  project  in  the 
competency  are  sent  to  SL.  As  such,  the  amount  of  incoming  data  saturates  SL 
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stakeholders,  who  do  not  have  any  specific  method  to  quickly  parse  through  the  updates. 
To  address  this  problem,  SL  began  to  ask  each  of  the  BHs  to  provide  quad-charts  with 
project  schedule,  risk,  and  funding  information  once  per  month.  This  request  levies 
additional  manual  work  on  BHs  and  PMs. 

SL  stakeholders  are  also  interested  in  exploring  the  number  of  personnel  in  the 
competency  by  division  and  branch.  Insight  into  the  manning  distribution  allows  SL  to 
make  more  informed  hiring  decisions.  Additionally,  SL  require  insight  into  the  high-level 
allocation  of  personnel  to  projects.  SL  currently  receive  updates  on  personnel  allocation 
and  utilization  once  or  twice  per  year  from  the  People  to  Project  spreadsheets  that  BHs 
maintain. 

2.  Qualitative  Capability  Gaps 

Each  of  the  current  processes  discussed  in  Chapter  II,  Section  A.l  are  insufficient 
for  meeting  each  group  of  stakeholders’  needs.  They  require  manual  work  and  rework  at 
all  levels  of  management.  Additionally,  due  to  their  lack  of  integration,  the  current 
processes  are  unable  to  take  advantage  of  modern  data  processing  and  chart-generation 
capabilities.  The  qualitative  capability  gaps  between  the  current  processes  and  a  system 
that  can  leverage  modern  technology  can  be  broken  down  into  three  distinct  problem 
areas:  time  delay  due  to  lead  times  to  process  data,  rework  of  management  products,  and 
inaccuracy  in  the  data  products.  The  following  paragraphs  described  each  of  these  in 
more  detail. 


a.  Time  Delay 

The  manual  nature  of  the  current  data  entry  processes  inhibits  the  efforts  to 

effectively  maintain  an  accurate  and  current  picture  of  the  competency’s  funds,  personnel 

and  schedule  status.  Although  BFMs  have  integrated  the  use  of  macros  for  data  fusion, 

these  macros  have  proven  to  be:  (i)  difficult  to  implement,  because  of  the  steps  required 

to  prepare  the  data  to  use  the  macro  and  (ii)  inefficiently  coded  to  the  degree  that  the 

computer  periodically  freezes.  Since  there  is  no  central  file  location  for  storing  project 

data  within  the  competency,  and  there  is  no  integration  between  the  databases  outside  of 

the  competency,  the  BFMs  must  manually  download  data,  process  the  information,  enter 
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additional  data,  and  send  the  finished  product  to  recipients.  The  amount  of  time  required 
to  perform  these  steps  results  in  data  latency,  which  is  a  capability  gap.  The  result  is  that 
PM,  BH,  and  SL  stakeholders  do  not  have  access  to  the  most  accurate  and  updated 
information  when  making  decisions. 

In  addition  to  the  delays  on  the  BFM  side,  there  is  also  a  time  delay  on  the  PM 
side  when  they  collate  project  data  to  provide  to  BHs  on  a  weekly  basis.  Another  time 
delay  occurs  when  BHs  collate  and  process  the  data  from  the  various  PMs  to  provide  to 
SL.  These  delays  add  up,  making  the  process  increasingly  slower. 

The  final  time  delay  concern  relates  to  the  People  to  Project  spreadsheet,  which 
BHs  have  stated  is  cumbersome  to  use  when  managing  personnel  on  a  periodic  basis.  The 
reason  they  continue  to  use  it  is  that  SL  stakeholders  want  to  see  percentage  utilization  of 
personnel.  The  People  to  Project  spreadsheet  allows  BHs  to  do  that;  however,  the  steps 
necessary  to  populate  the  tracker  and  pull  the  desired  information  from  the  tool  are  time 
consuming.  During  Team  CAT’s  interviews,  the  BHs  suggested  adding  a  feature  to  view 
time  dimensions  with  respect  to  personnel  assignments  to  projects. 

b.  Rework 

Since  the  current  process  relies  heavily  on  manual  data  input,  it  becomes 
necessary  to  also  manually  update  the  data  points  and  metrics  used  to  monitor 
competency  progress  whenever  the  data  changes.  The  BFMs  must  frequently  refresh  the 
data,  since  the  information  of  interest,  such  as  changing  funding  levels  of  each  project  in 
the  competency,  changes  on  a  recurring  basis.  The  amount  of  rework  this  creates  deters 
BFMs  from  their  main  task  of  managing  the  financial  interests  of  the  competency.  This 
process  is  not  an  effective  use  of  manpower  in  NAV AIR’s  current  resource-constrained 
environment. 

BFMs  are  not  the  only  stakeholders  plagued  by  this  rework  cycle.  Each  time  BH 
stakeholders  receive  input  from  PMs,  they  are  required  to  reprocess/rework  that  data  to 
ensure  that  SL  only  receive  the  most  relevant  and  up-to-date  information  in  the  desired 
format. 
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c. 


Inaccurate 


In  addition  to  decisions  having  to  be  made  with  delayed  data,  the  inaccuracy  of 
that  data  is  another  problem  that  is  present  at  all  levels  of  management.  Not  only  does  the 
process  of  manual  data  entry  increase  the  potential  for  input  errors,  but  the  ad-hoc  nature 
of  PM  to  BH  reporting  means  that  there  is  no  common  reporting  format  or  standard.  As  a 
result,  it  falls  to  each  BH  to  collate  and  reformat  the  various  inputs  from  his  or  her  PMs, 
which  adds  another  potential  opportunity  to  introduce  errors.  All  these  factors  combine  to 
increase  the  perceived  likelihood  of  delivering  inaccurate  data. 

B.  STAKEHOLDER  ANALYSIS 

Team  CAT  believed  that  frequent  stakeholder  communication  was  a  key  factor 
for  designing  the  CAT  system.  The  following  sections  describe  the  assumptions  and 
processes  followed  by  the  team  to  identify  specific  stakeholders,  define  the  needs  of  each 
stakeholder  group,  and  translate  those  needs  into  user  stories. 

1.  Stakeholder  Identification 

As  discussed  in  the  previous  sections,  Team  CAT  decided  to  include  all  levels  of 
management  within  the  competency  as  stakeholders  for  this  project:  BFMs,  PMs,  BHs, 
and  SL.  Each  person  using,  viewing,  or  interacting  with  the  data  in  CAT  could  provide 
valuable  insight  into  the  capabilities  that  would  be  necessary  for  CAT  to  possess,  as  well 
as  prioritization  of  data  appearing  on  CAT’s  dashboards.  These  stakeholders  are  natural 
users  of  the  CAT  because  they  either  have  decision  making  responsibilities  and  are 
therefore  frequent  users  of  the  provided  data,  or  they  otherwise  have  responsibilities  that 
warrant  interaction  with  project  metrics. 

2.  Stakeholder  Needs  as  User  Stories 

The  first  SE  artifacts  developed  for  this  project  consisted  of  the  user  stories  for 
each  type  of  stakeholder.  Each  user  story  describes  the  specific  needs  elicited  from  the 
stakeholders.  As  seen  in  Figure  8,  Team  CAT  grouped  the  user  stories  into  five 
categories:  funding,  general  needs,  status  items,  personnel,  and  schedule  items.  Each  of 
these  categories  is  discussed  in  more  detail  in  the  following  sections. 
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Figure  8. 


CAT  User  Stories  Categories 


a.  Funding  User  Stories 

This  section  provides  the  list  of  funding-related  user  stories.  The  Funding  User 
Story  Hierarchy  Diagram  (Figure  9)  shows  the  stories  associated  with  managing 
competency  funding.  Table  1  provides  a  description  of  each  user  story.  For  funding 
management,  the  stakeholders  requested  that  they  be  able  to  view  a  graph  that  showed 
planned  versus  executed  project  funding.  This  would  allow  stakeholders  to  determine  if  a 
project  was  over-  or  under-expending  as  compared  to  a  planned  amount.  Furthermore,  the 
BFM  stakeholders  also  expressed  the  need  to  be  able  to  edit  all  the  fields  in  the  funding 
status  sheets  in  CAT.  Lastly,  the  stakeholders  expressed  that  oftentimes  they  did  not 
know  when  their  projects’  funds  were  expiring  since  different  funds  expire  at  different 
times.  As  such,  they  expressed  a  need  to  view  when  funding  was  expiring  to  be  able  to 
plan  appropriately. 


Figure  9.  Funding  User  Stories  Hierarchy  Diagram 
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Table  1.  Descriptions  of  Funding  User  Stories 


Name 

Number 

Description 

View  Funding 
Expiration 
Information 

US.F.l 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  funding 
expiration  dates 

View  Spend  Plans 

US.F.2 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  spend 
plans 

View  Planned 
versus  Actual 
Expenditures 

US.F.3 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  planned 
versus  actual  expenditures.  I  want  to  know,  based  off  my 
current  project  expenditure  rate,  if  I  will  over-  or  under¬ 
expend. 

Create  Spend  Plan 

US.F.4 

As  the  PM,  I  want  to  be  able  to  create  a  spend  plan  in  the 
system. 

View  and  Edit  All 
Funding  Status 
Sheets 

US.F.5 

As  the  BFM,  I  want  to  view  and  edit  a  web-based  copy 
of  the  funding  status  sheets  (i.e.,  “Longsheets”). 

b.  Status  Items  User  Stories 

This  section  provides  the  list  of  user  stories  for  entering  and  viewing  project 
status  information.  The  term  “status  items,”  when  used  in  relation  to  CAT,  refers  to  any 
general  information  item  that  PMs  wish  to  communicate  to  their  BHs.  For  example,  a  PM 
may  want  to  inform  the  BH  that  the  project  team  is  on  schedule  to  meet  a  specific 
deliverable  or  that  the  team  needs  additional  personnel  resources.  The  stakeholders  also 
requested  that  they  be  able  to  use  the  colors  red,  yellow,  or  green,  to  indicate  subjectively 
whether  or  not  a  status  item  was  either  (i)  one  that  needed  immediate  attention,  (ii)  one 
that  the  PM  and  BH  should  keep  an  eye  on,  or  (iii)  one  that  was  just  a  general  update 
requiring  no  additional  actions.  The  Status  Item  User  Stories  Hierarchy  Diagram  (Figure 
10)  shows  the  main  user  stories  associated  with  managing  projects’  status  items.  Table  2 
provides  a  description  of  each  user  story. 
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Status  Item 
User  Stories 


Figure  10.  Status  Item  User  Stories  Hierarchy  Diagram 


Table  2.  Description  of  Status  Item  User  Stories 


Name 

Number 

Description 

View  List  of  Status 
Items 

US.SI.  1 

As  the  PM,  BH,  or  SL,  I  want  to  view  projects’  status 
items  with  priority  subjectively  labelled  as  red,  yellow,  or 
green. 

Enter  Status  Item 
Information 

US.SI.2 

As  the  PM,  I  want  to  input  project  status  item  information. 

c.  Personnel  User  Stories 

This  section  provides  the  list  of  user  stories  for  managing  personnel  within  the 
competency.  The  BH  stakeholders  expressed  several  capabilities  they  wanted  CAT  to 
perform,  including  (i)  the  ability  to  assign  personnel  to  different  projects,  (ii)  the  ability 
to  view  how  each  employee  will  be  utilized  throughout  the  year,  and  (iii)  the  ability  to 
assign  specific  projects  to  project  managers. 

Additionally,  SL  stakeholders  expressed  their  own  desired  capabilities  for  CAT, 
including  the  ability  to  view  how  many  people  are  in  each  competency’s  divisions  and 
branches,  and  the  ability  to  view  the  personnel  utilization  data  managed  by  BHs.  The 
Personnel  User  Story  Hierarchy  Diagram  (Figure  11)  shows  the  user  stories  associated 
with  managing  competency  personnel.  Table  3  provides  a  description  of  each  user  story. 
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Figure  11.  Personnel  Management  User  Story  Hierarchy  Diagram 


Table  3.  Descriptions  of  Personnel  Management  User  Stories 


Name 

Number 

Description 

Assign  personnel 
to  projects 

US.P.l 

As  the  BH,  I  want  to  assign  personnel  to  projects. 

Assign  Project 
Manager  to  a 
project 

US. P.2 

As  the  BH,  I  want  to  assign  project  managers  to 
projects. 

View  Personnel 
Utilization 

US. P.3 

As  the  BH  or  SL,  I  want  to  view  personnel  utilization 
for  projects  over  a  period  of  time. 

View  Competency 
Manning  Levels 

US. P.4 

As  the  SL,  I  want  to  view  the  competency’s  manning 
levels. 

d.  Schedule  Item  User  Stories 

This  section  describes  and  provides  the  list  of  user  stories  related  to  managing  and 
viewing  project  schedule  items.  PM  and  BH  stakeholders  expressed  the  need  to  specify 
and  track  key  project  milestone  dates  (such  as  a  preliminary  design  review  (PDR))  or 
deliverable  due  dates  (such  as  a  project  Study  Plan).  They  requested  that  CAT  display 
this  information  in  both  tabular  and  timeline  format. 

Additionally,  each  time  a  user  created  a  schedule  item,  stakeholders  requested  that 
the  item  require  approval  from  a  BH.  They  requested  for  the  BH  to  receive  alerts  anytime 
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a  schedule  item  was  coming  due  or  if  a  project  manager  indicated  completion  of  a 
particular  status  item.  The  Schedule  Item  User  Story  Hierarchy  Diagram  (Figure  12) 
shows  the  user  stories  associated  with  managing  schedule  items.  Table  4  provides  a 
description  of  each  user  story. 
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Figure  12.  Schedule  Item  User  Story  Hierarchy  Diagram 


Table  4.  Descriptions  of  Schedule  Items  User  Stories 


Name 

Number 

Description 

Create  Schedule 
Items 

US.S.l 

As  the  PM  or  BH,  I  want  to  be  able  to  create  schedule 
items. 

Accept/Deny 
Proposed 
Completion  Dates 

US.S.2 

As  the  BH,  I  want  to  be  able  to  accept  or  deny  schedule 
items’  completion  dates  proposed  by  the  PM. 

Assign  Projected 
Completion  Dates 

US.S.3 

As  the  PM  or  BH,  I  want  to  assign  projected  completion 
dates  for  all  schedule  items. 

View  Schedule 
Items  List 

US.S.4 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  schedule 
items. 

Receive  Alert  for 
Completed 
Schedule  Items 

US.S.5 

As  the  BH,  I  want  to  receive  alerts  when  schedule  items 
are  marked  as  complete. 

Mark  when  items 
are  completed 

US.S. 6 

As  the  PM,  I  want  to  mark  when  schedule  items  are 
completed. 

Receive  Alert 
when  items  are 
coming  due 

US.S.7 

As  the  BH,  I  want  to  receive  alerts  when  schedule  items 
are  marked  as  complete. 

View  Schedule 
Items  Timeline 

US.S.8 

As  the  PM,  BH,  or  SL,  I  want  to  see  projects’  schedule 
items  on  a  timeline. 
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e.  General  User  Stories 

This  section  provides  the  list  of  miscellaneous  user  stories  that  did  not  fit  into  any 
of  the  aforementioned  categories,  including  general  functions  available  to  all  users  in 
CAT.  The  stories  include  the  capability  for  users  to  view  all  projects  of  interest,  as  well 
as  to  export  reports.  In  the  scenario  where  a  user  story  applied  to  all  users,  Team  CAT 
documented  the  user  story  as  “As  the  user,  I  want...”  as  opposed  to  incorporating  each 
user  type  at  the  start  of  the  story.  Figure  13  illustrates  the  hierarchy  for  these  general  user 
stories,  and  Table  5  provides  a  description  of  each  user  story. 
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Figure  13.  General  User  Stories  Hierarchy  Diagram 


Table  5.  Descriptions  of  General  User  Stories 


Name 

Number 

Description 

Export  Reports 

US.G.l 

As  the  user,  I  want  to  export  reports  for  all  artifacts 
from  the  system. 

View  All  Projects 
Under  Purview 

US.G.2 

As  the  PM,  BH,  or  SL,  I  want  to  see  all  projects  for 
which  I  have  permission. 
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C.  USE  CASE  DEVELOPMENT 

After  eliciting  and  analyzing  the  user  stories,  Team  CAT  derived  use  cases  to 
better  understand  the  interactions  between  the  users  and  the  CAT  system  at  the 
operational  level.  This  included  tracing  all  use  cases  to  user  stories.  To  communicate  to 
each  stakeholder  how  he  or  she  would  interact  with  CAT,  the  team  delivered  the  use 
cases  in  the  form  of  use  case  diagrams  and  sequence  diagrams.  During  IPR  1,  Team  CAT 
referred  to  these  diagrams  directly,  which  helped  to  focus  the  stakeholders’  feedback.  By 
confirming  or  denying  the  use  cases,  the  stakeholders  provided  Team  CAT  with  critical 
design  guidance  to  make  the  system  a  valid  one. 

Additionally,  Team  CAT  leveraged  the  use  cases  to  generate  requirements, 
maintain  traceability,  and  verify  that  every  requirement  traced  back  to  a  use  case  and  user 
story.  Section  C.2  further  discusses  the  traceability  between  user  stories  and  use  cases, 
while  Chapter  III,  Section  E  discusses  the  traceability  between  the  developed  use  cases 
and  requirements. 

To  remain  consistent  with  NAVAIR  standards,  Team  CAT  used  the  Program 
Executive  Office  for  Unmanned  Aviation  and  Strike  Weapons’  (PEO(U&W))  standard 
template  for  capturing  use  cases  (PEO(U&W)  n.d.).  Using  the  template  allowed  Team 
CAT  to  identify  (i)  the  exact  purpose  of  each  use  case,  (ii)  the  stakeholders  that  would 
require  permissions  within  CAT  to  execute  that  use  case,  and  (iii)  the  interactions 
required  between  the  users  and  CAT  to  execute  each  use  case.  Figure  14  illustrates  the 
PEO(U&W)  template. 


27 


ZT\ 


Figure  14.  PEO(U&W)  Use  Case  Template 

1.  Example  Use  Case 

By  using  the  PEO(U&W)  use  case  standard,  Team  CAT  remained  consistent  with 
NAVAIR  practices,  while  accentuating  the  system  design  process.  This  emphasis 
afforded  the  team  the  opportunity  to  better  understand  the  functionality  CAT  would 
require  to  support  interactions  with  external  entities  such  as  NERP,  Command  Staffing, 
and  the  users.  To  identify  the  interactions,  Team  CAT  converted  each  of  the  use  cases’ 
activity  flows  to  sequence  diagrams,  resulting  in  a  graphical  representation  of  each  use 
case.  The  following  page  includes  an  example  text-based  use  case  following  the 
PEO(U&W)  standard.  Appendix  E  provides  the  exhaustive  set  of  use  cases. 
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Example  Text-Based  Use  Case 
UC.ALL.l  EXPORT  REPORTS 
User  Story: 

As  the  user,  I  want  to  export  reports  for  all  artifacts  from  the 

system. 

Description:  CAT  users  request  the  option  to  export  information 
for  printing  or  saving.  The  user  needs  to  be  able  to  choose  which 
information  should  be  included  in  the  exported  file  by  selecting 
information,  such  as  funding  graphs,  personnel  lists,  or  funding  sheets, 
from  his  or  her  dashboard  and  selecting  the  destination  for  the  exported 
file.  Depending  on  the  type  of  report,  the  format  will  either  be  in 
Microsoft  Excel  (.xlsx),  Microsoft  Word  (.docx),  or  Microsoft  PowerPoint 
(.pptx)  formats. 

Assumptions:  CAT  contains  the  information  required  for  the 

artifact  the  user  wants. 

Participants:  All  users 

Pre-conditions:  The  user  is  logged  into  the  system. 

Post-conditions:  CAT  provides  the  exported  artifact  to  the  user  in 

the  required  format. 

Flows: 

•  Primary  Flow: 

o  User  requests  to  export  a  CAT  artifact 

o  CAT  provides  options  of  artifacts  that  can  be  exported 

o  User  selects  artifact(s)  to  export 

o  User  selects  format  of  artifacts  to  export 

o  CAT  requests  location  to  download  artifact 

o  User  provides  location 

o  CAT  provides  exported  artifact 
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Team  CAT  created  the  use  case  diagram  shown  in  Figure  15  to  capture  the  use 
cases  in  an  architecture.  Although  the  diagram  appears  simple,  it  formally  establishes  the 
relationship  between  the  specific  use  case  and  its  performer.  In  this  scenario,  the  “Any 
User”  actor  represents  the  BFM,  PM,  BH,  and  SL  users. 


Figure  15.  Use  Case  Diagram  for  “Export  Reports”  Use  Case 

In  addition  to  modeling  use  cases  with  use  case  diagrams,  Team  CAT  modeled 
the  interactions  discussed  in  each  use  case  using  sequence  diagrams.  By  using  sequence 
diagrams,  Team  CAT  was  able  to  explore,  derive,  and  communicate  interface 
requirements  with  the  stakeholders.  The  sequence  diagram  in  Figure  16  demonstrates  the 
flow  progression  present  in  the  Example  Text-Based  Use  Case. 
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Figure  16.  Sequence  Diagram  for  “Export  Reports”  Use  Case 
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2.  Traceability  between  User  Stories  and  Use  Cases 

Figure  17  illustrates  how  Team  CAT  traced  each  use  case  to  at  least  one  user 
story,  while  Appendix  F  provides  a  readable  tabular  layout  of  the  traceability  depicted  in 
Figure  17.  By  auditing  the  traceability  between  user  stories  and  use  cases,  Team  CAT 
determined  that  some  user  stories  did  not  have  any  use  cases,  and  reversely,  some  use 
cases  referred  to  by  stakeholders  were  not  represented  in  the  user  stories.  This  led  to  a 
refinement  of  the  artifacts  through  a  process  of  iterative  evaluation.  This  iterative 
evaluation  also  enabled  Team  CAT  to  determine  whether  specific  use  cases  and  user 
stories  needed  to  be  combined  because  of  similarities  or  whether  the  team  had  identified 
realistic  gaps  in  the  model. 

Lastly,  Team  CAT  developed  the  use  case-numbering  schema  to  reflect  the 
primary  actors  in  the  given  story.  Note  that  some  use  cases  traced  to  multiple  user  stories 
simply  because  the  stories  were  similar  in  nature  and  could  be  fulfilled  by  a  singular  use 
case. 
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Figure  17.  Traceability  Between  Use  Cases  and  User  Stories 


D.  CHAPTER  SUMMARY 

Team  CAT  implemented  the  UP  by  first  identifying  the  processes  currently  being 
followed  by  the  stakeholder  competency.  The  team  noted  that  each  level  of  management 
within  the  competency  was  interested  in  reviewing  different  degrees  of  project  detail, 
which  led  to  different  preferences  in  formatting  and  content  for  reports.  From  these 
observations,  Team  CAT  was  able  to  identify  three  significant  qualitative  capability  gaps: 
time  delay,  rework,  and  higher  risk  of  data  inaccuracy.  Since  it  was  evident  that  each 

competency  management  role  could  provide  valuable  insight  into  the  expected 
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capabilities  of  CAT,  the  team  decided  to  include  all  levels  of  management  as 
stakeholders. 

The  user  stories  were  the  first  SE  artifact  developed,  with  each  user  story 
describing  the  needs  of  each  management  role.  Team  CAT  grouped  these  user  stories  into 
five  categories:  funding,  general  needs,  status  items,  personnel,  and  schedule  items.  From 
the  information  provided  in  the  user  stories,  the  team  was  able  to  develop  use  cases  to 
better  understand  the  interactions  between  the  users  and  the  system  at  an  operational 
level.  Use  cases  included  textual  elements  describing  the  use  case,  use  case  diagrams,  and 
sequence  diagrams.  From  the  use  cases,  Team  CAT  was  able  to  generate  requirements, 
maintain  traceability,  and  verify  that  every  requirement  traced  back  to  a  use  case  and  user 
story. 

The  team  placed  emphasis  on  tracing  each  use  case  to  at  least  one  user  story.  By 
auditing  the  traceability  between  user  stories  and  use  cases,  Team  CAT  discovered  that 
some  user  stories  did  not  have  use  cases.  Conversely,  some  use  cases  were  not 
represented  in  the  user  stories.  This  led  to  a  refinement  of  the  artifacts  through  a  process 
of  iterative  evaluation. 
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III.  REQUIREMENTS  ANALYSIS 


Following  the  documentation  of  user  stories  and  use  cases,  Team  CAT  proceeded 
to  analyze  those  SE  artifacts  iteratively,  by  deriving  and  decomposing  the  system 
requirements.  The  team  used  these  requirements  to  establish  the  conditions  the  system 
needed  to  meet  to  satisfy  stakeholder  needs.  The  requirements  analysis  process  served  to 
formally  define  system  behavior  and  expectations  in  a  way  that  was  quantifiable, 
relevant,  detailed,  and  fully  traceable  to  parent  artifacts. 

Section  A  of  this  chapter  discusses  how  affinity  diagramming  was  used  to  group 
requirements  into  logical  categories  for  ease  of  analysis.  Section  B  discusses  how  the 
Easy  Approach  to  Requirements  Syntax  (EARS)  method  was  used  to  write  testable 
requirements.  Section  C  provides  examples  of  specific  derived  requirements  used  to 
decompose  the  top-level  requirements  into  lower-level  behavior  in  greater  detail.  Section 
D  discusses  how  the  top-level  requirements  were  traced  to  CAT  use  cases.  Lastly, 
Section  E  provides  a  short  summary  of  the  entire  requirements  analysis  phase  of  the  CAT 
system  development  process. 

A.  AFFINITY  DIAGRAMMING  TO  CATEGORIZE  REQUIREMENTS 

In  chapter  6  of  the  book  The  Engineering  Design  of  Systems:  Models  and 
Methods  (Buede  2009),  the  author  suggests  the  use  of  a  requirements  organization 
framework  to  help  define  and  group  requirements.  The  use  of  this  framework  also  aids  in 
the  decomposition  of  requirements  into  functions  and  facilitates  the  verification  and 
validation  of  traceability. 

Team  CAT  started  the  affinity  diagramming  process  by  using  the  online 
collaboration  tool  RealtimeBoard.  The  team  explored  the  relationships  between  use  cases 
and  user  stories  and  grouped  them  into  top-level  hierarchical  parent  categories  with 
children  subgroups.  With  RealtimeBoard’ s  virtual  sticky  notes,  Team  CAT  was  able  to 
organize  the  thoughts,  ideas,  and  inputs  from  each  stakeholder  group  without  attributing 
them  to  a  specific  user.  This  approach  resulted  in  a  logical  organization  schema  for 
requirements,  which  ensured  that  every  requirement  could  be  traced  back  to  a  use  case 
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and  user  story.  The  RealtimeBoard  affinity  diagram  for  the  CAT  system  is  presented  in 
Figure  18,  with  Appendix  G  (Figures  G-l  to  G-7)  providing  a  detailed  visual 
representation  of  each  grouping.  The  affinity  diagram  served  as  the  baseline  requirements 
structure  in  which  Team  CAT  could  define  the  CAT  system’s  specific  inputs,  outputs, 
and  internal  functions. 
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Using  the  results  of  the  affinity  diagramming  exercise,  as  well  as  the  material 
from  Buede’s  book,  Team  CAT  categorized  the  requirements  into  five  main  categories: 

1 .  User  profile  requirements 

2.  Project  schedule  item  requirements 

3.  Project  funding  requirements 

4.  People  to  project  requirements 

5.  Project  status  item  reporting  requirements 

The  team  then  decomposed  these  five  requirement  categories  further,  into  the 
following  subcategories: 

•  System  input  requirements 

•  System  output  requirements 

•  System  functional  requirements 

Team  CAT  defined  system  input  requirements  to  include  the  inputs  the  CAT 
system  must  receive  from  external  entities,  system  output  requirements  to  include  the 
outputs  the  CAT  system  must  produce,  and  system  functional  requirements  to  include  the 
specific  functions  the  CAT  system  must  perform  while  transforming  the  inputs  into 
outputs. 

One  additional  category  referred  to  by  Buede  is  “System- wide  Requirements.” 
These  system-wide  requirements  typically  characterize  the  CAT  system  as  a  whole  and 
are  usually  non-functional  in  nature.  In  chapter  6,  section  5.4  of  his  book,  Buede  (2009) 
states: 

System-wide  requirements  (often  called  “-ilities”)  are  characteristics 

of  the  entire  system;  examples  include  availability,  reliability, 

maintainability,  durability,  supportability,  safety,  trainability,  testability, 

extensibility  (growth  potential),  and  affordability  (e.g.,  operating  cost) 

Team  CAT  created  generic  system-wide  placeholders  for  the  non-functional  requirements 
category.  To  stay  within  project  scope,  the  team  decided  to  decompose  only  a  subset  of 
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these  system-wide  requirements,  specifically  those  related  to  compatibility,  usability,  and 
security. 

To  define  fully  the  system  functionality.  Team  CAT  decomposed  the  top-level 
requirements  at  the  parent  categories  into  derived  requirements.  Derived  requirements  are 
those  that  may  not  have  been  explicitly  stated  or  requested  by  the  stakeholders,  but  are 
still  necessary  to  satisfy  the  intent  and  expected  functionality  of  the  proposed  system. 
They  differ  from  gold-plating  or  requirements  creep  in  that  they  are  not  wants  or  “nice  to 
haves,”  but  critical  to  the  success  of  the  system  meeting  the  stakeholder  needs  and 
required  system  capabilities. 

B.  STANDARDIZATION  OF  REQUIREMENTS 

During  the  requirements  documentation  process,  Team  CAT  came  to  the 
realization  that,  in  order  to  maintain  high  quality  and  constancy,  a  standardized  method  of 
writing  requirements  was  necessary.  The  standard  requirements  wording  used  for 
physical  systems  (such  as  aircraft  requirements  of  distance,  fuel  capacity,  or  speed)  did 
not  fit  the  context  of  a  software  system,  in  which  each  requirement  may  not  have  an 
allocated  numerical  measure  of  performance  or  effectiveness.  Before  arriving  at  this 
realization,  the  initial  set  of  requirement  statements  generated  by  Team  CAT  were  overly 
verbose,  repetitive,  and  their  inherent  testability  was  questionable.  To  fix  these  issues,  the 
team  decided  to  use  the  Easy  Approach  to  Requirements  Syntax  (EARS)  method  to 
communicate  unambiguous  requirements  clearly  and  consistently.  The  use  of  the  EARS 
method  is  one  of  the  recommended  methods  of  requirements  documentation  by  the  SE 
community,  because  it  consists  of  “reusable  statements  and  reusable  formats”  and  results 
in  the  elimination  of  “complexity,  omission,  duplication,  implementation  and 
untestability”  problems  (Mavin  et  al.  2009). 

The  EARS  method  uses  six  types  of  requirements  to  specify  a  system:  ubiquitous, 
event-driven,  unwanted  behaviors,  state  driven,  and  optional.  The  most  common  types  of 
requirements  encountered  by  Team  CAT  were  ubiquitous  and  event-driven.  Ubiquitous 
requirements  have  “no  preconditions  or  trigger”  and  are  “always  active.”  The  EARS 
method  has  a  “general  form”  or  “syntax”  for  each  requirement  type.  The  syntax  for 
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ubiquitous  requirements  is  as  follows:  “The  <system  name>  shall  <system  responsex” 
(Mavin  et  al.  2009,  319).  For  CAT,  this  type  of  requirement  takes  the  form  of:  “The  CAT 
system  shall  <system  responsex”  The  remaining  syntax  used  by  Mavin  et  al.  are  as 
follows: 

•  “Generic  requirements...  coptional  preconditions>  coptional  trigger>  the 
<system  name>  shall  <system  response>”  which  follows  “temporal  logic”  in 
that  it  implies  the  preconditions  or  trigger  must  be  true  before  the  response 
occurs”  (Mavin  et  al.  2009,  319). 

•  “Event-driven  requirements...  [take  the  form:]  WHEN  coptional 
preconditions>  <trigger>  the  csystem  name>  shall  csystem  responsex” 

•  “Unwanted  behaviours...  [take  the  form:]  IF  coptional  preconditions> 
ctriggerx  THEN  the  csystem  name>  shall  csystem  responsex” 

•  “State-driven  requirements...  [take  the  form:]  WHILE  cin  a  specific  state> 
the  csystem  name>  shall  csystem  responsex” 

•  “Optional  features...  [take  the  form:]  WHERE  cfeature  is  included>  the 
csystem  name>  shall  csystem  response>”  (Mavin  et  al.  2009,  320). 

Team  CAT  used  the  EARS  method  to  write  all  requirements,  using  the 
corresponding  syntax  for  the  type  of  requirement  being  defined.  While  there  are  few 
testable  parameters  events  within  CAT’s  requirements,  the  EARS  format  contains  an 
implicit  binary  style  of  testing,  as  the  requirements  define  a  condition  or  behavior  that 
can  be  falsifiable.  When  any  one  of  these  requirements  is  tested  or  demonstrated,  it  can 
either  be  true  or  false  and  is  therefore  testable. 

C.  CAT  SYSTEM  REQUIREMENTS 

The  following  sections  summarize  the  requirements  categories  used  as  the  starting 
point  for  deriving  the  full  list  of  functional  requirements  found  in  the  Requirements 
Traceability  Matrix  (RTM),  presented  in  Appendix  H.  Figure  19  provides  an  illustration 
of  the  CAT  requirements  categories.  Team  CAT  traced  each  of  these  categories  back  to 
use  cases,  and  in  turn  to  user  stories,  to  ensure  requirements  traceability.  Chapter  III, 
Section  D  provides  further  discussion  on  the  traceability  between  requirements  and  use 
cases. 
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Figure  19.  CAT  System  Design  Requirements  Categories 


While  decomposing  requirements,  Team  CAT  determined  that  software  systems 
rely  heavily  on  non-functional  requirements  that  define  suitability  constraints.  Since 
suitability  was  considered  out  of  scope  for  this  project,  the  team  did  not  decompose  the 
non-functional  requirements  in  detail.  Chapter  III,  Section  C.6  briefly  discusses  non¬ 
functional  requirements  and  how  the  few  example  non-functional,  system-wide 
requirements  decompositions  can  be  used  as  an  initial  baseline  to  guide  additional  non¬ 
functional  requirements  decomposition. 

1.  User  Profile  Requirements  [R.l] 

To  meet  the  specific  requests  of  each  stakeholder,  Team  CAT  determined  that  the 
CAT  system  shall  be  capable  of  establishing  a  user  profile  for  each  user.  Within  this 
profile,  the  user  shall  be  able  to  provide  inputs  to  the  CAT  system,  store  data  specific  to 
the  user,  and  display  that  data.  The  user  profiles  allow  the  creation  of  new  projects  within 
CAT  and  serve  as  the  customized  interface  for  each  stakeholder. 

To  satisfy  these  top-level  requirements,  Team  CAT  had  to  also  derive  additional 
requirements.  For  example,  one  top-level  requirement  was  for  CAT  to  have  the  capability 
to  create  a  new  project.  The  team  also  derived  the  requirement  for  CAT  to  be  capable  of 
accepting  the  input  of  a  project  start  date,  end  date,  and  project  description  inputs. 
Another  example  includes  the  requirement  for  CAT  to  be  capable  of  storing  user  data. 
From  this  requirement,  the  team  developed  the  derived  requirement  of  CAT  being 
capable  of  saving  data  from  user  inputs  and  external  databases.  All  of  these  derived 
requirements  served  to  define  further  the  functionality  that  stakeholders  expect  from  user 
profiles. 
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2.  Project  Schedule  Item  Requirements  [R.2] 

The  project  schedule  item  requirements  resulted  from  the  stakeholders’  need  to 
manage  project  milestone  and  deliverable  dates.  These  requirements  provide  the  users 
with  the  means  to  monitor  and  track  projects’  key  deliverables  and  schedule  items. 

To  satisfy  the  top-level  requirement  of  managing  scheduling  items,  Team  CAT 
had  to  derive  additional  requirements.  For  example,  one  of  the  top-level  schedule  item 
requirements  related  to  receiving  alerts  for  upcoming  milestones  or  deliverables.  To 
expand  upon  this  further,  Team  CAT  derived  the  requirement  that  CAT  must  first  be  able 
to  calculate  the  time  until  the  deliverable/milestone  due  date,  then  display  the  alert. 
Another  example  includes  the  requirement  for  CAT  to  be  capable  of  displaying  a  project 
timeline  containing  schedule  items.  From  this  top-level  requirement,  the  team  derived  the 
requirements  that  CAT  must  also  be  able  to  sort  and  filter  schedule  items,  to  display  the 
information  in  a  manner  tailored  by  the  user. 

3.  Project  Funding  Requirements  [R.3] 

As  a  result  of  the  stakeholders  expressing  the  desire  to  manage  project  funding 
execution,  CAT  had  to  be  capable  of  meeting  specific  requirements  for  displaying 
funding  status.  Firstly,  the  stakeholders  requested  that  CAT  be  compatible  with  external 
funding  databases  (i.e.,  NERP)  and  funding  data  file  formats  so  that  CAT  may  ingest 
funding  data.  Secondly,  the  stakeholders  expressed  the  desire  to  be  able  to  create  and 
manage  spend  plans  for  specific  projects.  The  capability  to  display  actual  expenditures 
and  projected  funding  information  would  allow  all  stakeholders  to  monitor  project 
expenditures  in  a  single  system. 

To  satisfy  these  funding  requirements,  Team  CAT  had  to  derive  additional 
requirements.  For  example,  in  order  for  CAT  to  be  able  to  display  a  planned  versus  actual 
expenditure  chart  for  a  specific  project,  the  team  determined  that  the  system  must  be  able 
to  calculate  current  expenditures,  allow  for  creating  spend  plans  with  planned  spending, 
pull  data  from  a  spend  plan,  and  also  calculate  the  amount  of  over/under  spending. 

The  stakeholders  also  requested  the  capability  to  view  when  a  project’s  funding 

expired.  To  derive  the  requirements  for  this  functionality,  Team  CAT  had  to  create 
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sample  expenditure  calculation  spreadsheets.  This  helped  determine  how  to  calculate 
funding  burndown  and  illustrate  funding  expiration  to  users.  Chapter  IV,  Section  B 
provides  further  discussion  of  this  process,  and  Appendix  J  provides  the  screenshots  of 
the  spreadsheets  with  example  calculations. 

4.  People  to  Project  Requirements  [R.4] 

By  developing  the  user  stories  and  use  cases,  Team  CAT  was  able  to  identify 
requirements  related  to  managing  the  personnel  supporting  each  competency  project. 
Stakeholders  requested  that  CAT  have  the  capability  to  allow  users  to  view  and  manage 
the  number  of  personnel  assigned  to  a  specific  project.  They  also  desired  the  capability  to 
determine  each  employee’s  availability  for  project  assignment.  These  people-to-project 
features  would  provide  stakeholders  with  a  better  awareness  of  personnel  utilization. 

To  satisfy  these  personnel  management  requirements,  Team  CAT  had  to  derive 
further  requirements.  For  example,  for  the  requirement  that  CAT  be  able  to  display  which 
personnel  are  available  for  tasking.  Team  CAT  derived  the  requirement  that  CAT  must 
first  be  able  to  calculate  the  percentage  allocation/utilization  of  personnel  on  projects. 

5.  Project  Status  Item  Reporting  Requirements  [R.5] 

CAT  must  also  be  able  to  provide  a  means  for  Project  Managers  to  communicate 
project  status  items  to  Branch  Heads  and  Senior  Leadership.  This  would  include  project 
risks,  updates,  or  simple  binary  status  changes  such  as  “project  funding  not  yet  received.” 
to  “project  funding  now  received.”  The  intent  of  CAT  meeting  project  status  reporting 
requirements  is  to  have  functionality  that  will  allow  leadership  to  be  aware  of  notable 
items  for  a  project  and  to  react  early  to  resolve  potential  chokepoints  within  the  project 
management  process. 

To  elaborate  on  status  item  reporting  requirements,  Team  CAT  further 
decomposed  the  top-level  requirements.  For  example,  for  the  requirement  that  CAT  must 
be  able  to  alert  Branch  Heads  on  new  status  items,  Team  CAT  developed  the  derived 
requirement  that  CAT  accept  a  specific  user  input  that  actually  creates  the  status  item, 
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using  the  CAT  interface.  Additionally,  it  was  determined  that  CAT  must  accept  textual 
input  from  the  Project  Manager  to  explain  each  status  item  to  the  Branch  Head. 

6.  System-Wide  (Non-functional)  Requirements  [R.6] 

During  initial  interviews  with  stakeholders,  each  stakeholder  group  expressed  the 
desire  for  the  system  to  be  compatible  with  the  current  infrastructure,  intuitive  to  use,  and 
able  to  protect  sensitive  information.  Team  CAT  considered  these  non-functional 
requirements  to  be  beyond  the  scope  of  this  project;  however,  the  team  has  documented 
the  stakeholders’  desires  for  the  CAT  system  to  be  usable,  reliable,  maintainable, 
sustainable,  and  affordable.  Documenting  the  desires  of  the  stakeholder  groups  for 
elaboration  on  the  non-functional  requirements  ensures  that  future  development  teams 
can  further  explore  those  areas.  Team  CAT  minimally  addressed  compatibility  and 
security  as  part  of  the  initial  baseline;  however,  the  stakeholder  competency  should 
explore  the  remaining  system-wide  requirements  during  follow-on  work.  Chapter  VI 
contains  further  discussion  on  potential  areas  for  future  work.  Figure  20  illustrates  the  set 
of  non-functional  requirements  that  serve  as  a  starting  point  for  further  exploration  of 
non-functional  requirements. 
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Figure  20.  System-Wide  Non-functional  Requirements  Hierarchy 
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D.  TRACEABILITY  TO  USE  CASES 


Team  CAT  documented  the  traceability  of  top-level  requirements  to  the  use  cases 
presented  in  Chapter  II.  The  traceability  ensures  that  each  requirement  has  a  purpose  (i.e., 
fulfills  a  specific  use  case)  and  that  no  superfluous  requirements  exist  (i.e.,  requirements 
not  traced  to  use  cases). 

Figure  21  illustrates  how  the  top-level  requirements  trace  to  at  least  one  of  the 
sixteen  use  cases  captured  for  this  project.  Note  that  the  system-wide  non-functional 
requirements  do  not  trace  to  use  cases,  since  they  (i)  are  included  as  placeholders  for 
follow-on  work  and  (ii)  are  non-functional  requirements,  which  may  not  necessarily  trace 
to  any  functions  that  would  support  a  given  use  case.  Table  6  lists  the  use-cases  to 
requirements  traceability  illustrated  in  Figure  21. 


Figure  21.  CAT  Requirements  Traced  to  User  Stories 
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Table  6.  Requirements  to  Use  Case  Traceability  and  Detailed  Description 


Requirement 

Number 

Requirement 

Name 

Use  Case 
Number 

Use  Case 

Name 

R.l 

User  Profile 
Requirements 

UC.ALL.l 

Export  Reports 

UC.PM&BH&SL.2 

View  Projects  Under  Purview 

R.2 

Project  Schedule 
Item  Requirements 

UC.PM&BH&SL.  1 

Project  Schedule  Items  in  a 
List  or  on  a  Timeline 

UC.PM&BH.  1 

Create  Schedule  Items  and 
Assign  Completion  Dates 

UC.PM&BH.2 

Receive  Alerts  When  Items 
are  Coming  Due 

UC.PM&BH.3 

Mark  Schedule  Items  as 
Complete 

R.3 

Project  Funding 
Requirements 

UC.BFM.l 

View  and  Edit  Funding  Status 
Sheets 

UC.PM&BH&SL.4 

View  Spend  Plans 

UC.PM&BH&SL.5 

View  Funding  Expiration 
Dates 

UC.PM&BH&SL.6 

View  Planned  Versus  Actual 
Spending 

UC.PM.2 

Create  Spend  Plan 

R.4 

People  to  Project 
Requirements 

UC.BH&SL.  1 

View  Personnel  Utilization 

UC.BH.l 

Assign  Personnel  to  Projects 

UC.SL.l 

View  Competency  Manning 
Levels 

R.5 

Project  Status  Item 
Reporting 
Requirements 

UC.PM&BH&SL.3 

View  List  of  Status  Items 

UC.PM.l 

Enter  Status  Item  Information 

E.  CHAPTER  SUMMARY 

Team  CAT  was  able  to  define  and  organize  the  CAT  requirements  effectively, 
based  on  the  user  stories  and  use  cases  presented  in  Chapter  II.  The  team  used 
RealtimeBoard  to  execute  affinity  diagramming  methods,  which  enabled  the  team  to 
define  the  relationships  between  use  cases  and  user  stories,  group  them  accordingly,  and 
begin  categorizing  requirements.  This  resulted  in  five  categories  of  requirements:  user 
profile  requirements,  project  schedule  item  requirements,  project  funding  requirements, 
people  to  project  requirements,  and  project  status  item  reporting  requirements. 
Additionally,  the  team  decomposed  each  of  the  five  main  categories  into  three 
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subcategories:  system  input  requirements,  system  output  requirements,  and  system 
functional  requirements. 

Although  Team  CAT  considered  and  developed  several  non-functional 
requirements,  including  compatibility,  usability,  and  security,  the  team  did  not  further 
decompose  these  requirements,  due  to  limited  project  scope.  The  team  also  determined 
that  CAT  required  several  derived  requirements  to  satisfy  specific  top-level  requirements. 
These  included  mostly  software- specific  system  requirements,  such  as  the  capability  to 
accept  inputs  or  the  capability  to  calculate  percentages. 

To  clearly  and  consistently  communicate  unambiguous  requirements,  Team  CAT 
used  the  EARS  method  to  write  all  requirements  with  the  corresponding  syntax.  The  use 
of  EARS,  which  contains  an  implicit  binary  style  of  testing  of  “true”  or  “false,”  ensured 
each  requirement  was  testable.  Lastly,  the  team  documented  the  traceability  of  top-level 
requirements  to  the  originating  use  cases,  which  ensured  limitation  of  unnecessary, 
excessive  requirements. 
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IV.  FUNCTIONAL  ARCHITECTURE  DEVELOPMENT  AND 

ANALYSIS 


After  Team  CAT  established  the  system  requirements,  they  were  able  to  develop 
the  high-level  functional  architecture  for  the  system,  tracing  every  function  to  at  least  one 
requirement.  This  ensured  the  architecture  fulfilled  each  of  the  functional  requirements  in 
terms  of  both  function  and  data  flow.  The  team  created  a  functional  decomposition  first 
to  allow  hierarchical  organization  of  the  system  functions.  This  also  permitted  the  team  to 
define  all  the  functions  needed  to  fulfill  each  requirement.  Team  CAT  then  arranged  the 
functions  from  the  decomposition  into  action  diagrams  to  model  both  the  data  flow  and 
functional  flow  through  the  system. 

Section  A  of  this  chapter  contains  the  functional  decomposition  with  example 
action  diagrams.  Section  B  describes  informal  modeling  of  personnel  allocation  and 
funding  calculations  that  Team  CAT  used  to  verify  the  identification  of  a  complete  set  of 
requirements  and  functions.  Lastly,  Section  C  contains  a  description  of  the  requirements 
traceability  matrix  (RTM),  which  the  team  used  to  verify  that  every  functional 
requirement  was  traced  to  at  least  one  function,  and  vice  versa. 

A.  FUNCTIONAL  DECOMPOSITION  AND  FUNCTIONAL  FLOW/DATA 

TRANSFORMATION  MODELS 

This  section  presents  the  high-level  functional  decomposition  and  action  diagrams 
for  CAT,  while  Appendix  I  contains  the  fully  detailed  functional  decomposition  and 
action  diagrams.  Team  CAT  used  the  requirements  derived  in  Chapter  III  as  the 
foundation  for  conducting  the  functional  decomposition,  to  trace  each  system  function  to 
at  least  one  requirement.  The  purpose  was  to  decompose  the  functionality  of  CAT  into  its 
constituent  parts,  then  further  decompose  each  sub-function  into  progressively  more 
detailed  sub-functions.  Further  functional  architecture  development  in  the  form  of  action 
diagrams  supports  each  level  of  functional  decomposition.  The  action  diagrams  provide  a 
functional  model  to  define  and  communicate  the  data  flow  between  functions,  and  to 
elaborate  the  interaction  between  assets  and  resources  (Steiner  2016,  23).  The  action 
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diagrams  for  the  first  two  levels  of  the  functional  decomposition  hierarchy  are  included  in 
this  chapter,  while  Appendix  I  contains  additional,  more  detailed  action  diagrams. 

The  highest  level  function  of  the  functional  decomposition,  function  F.O,  captures 
the  overarching  project  mission.  It  encompasses  the  performance  of  all  subfunctions 
required  for  the  operation  of  CAT.  Figure  22  shows  function  F.O  and  its  first-level 
decomposition  into  four  broad  sub-functions.  The  first  function,  F.l,  is  “perform  sign-on 
functions.  ”  This  function  supports  the  requirements  that  specify  a  user  must  be  able  to 
use  his  or  her  credentials  to  gain  access  to  the  system. 

Once  CAT  recognizes  and  grants  access  to  a  user,  the  system  invokes  function  F.2 
to  match  the  user  to  his  or  her  profile.  This  function  also  provides  the  custom  competency 
management  tools  that  encompass  the  core  functionality  of  CAT.  Upon  completion  of  the 
user’s  competency  management  tasks,  function  F.3  provides  session  termination,  and 
function  F.4  provides  data  storage  and  retrieval. 
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Figure  22.  First-Level  F.O  Functional  Decomposition 


The  F.O  action  diagram  shown  in  Figure  23  illustrates  the  interplay  of  data 
transfer  between  the  CAT  functions  as  the  user  progresses  through  a  CAT  session.  The 
first  three  functions  are  linear:  the  user  logs-in,  uses  the  system,  and  logs-out.  The  fourth 
function,  F.4,  includes  data  storage  relating  to  functions  F.2  and  F.3.  The  “perform  data 
storage”  function  accounts  for  retrieval  of  the  user  profile  and  for  modifications  to  the 
individual  users’  dashboard  information.  As  such,  the  “perform  competency 
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administration  ”  and  “perform  session  termination  ”  functions  utilize  and  rely  directly  on 
the  data  storage  function. 
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Perform  Sign  _ 
on  Functions 


^  Operations 


Figure  23.  F.O  Action  Diagram 


1.  Perform  Sign-On  Functions  [F.l] 

Function  F.l,  shown  in  Figure  24,  consists  of  four  sub-functions.  The  purpose  of 
this  particular  parent  function  is  to  provide  the  user  access  to  the  human-computer 
interface  (i.e.,  to  allow  the  user  to  log-in  [function  F.1.1]).  The  user  initiates  log-in  by 
inserting  the  DOD  common  access  card  (CAC)  into  the  computer.  CAT  requests  the 
user’s  CAC  credentials  in  the  form  of  electronic  certificates.  CAT  transmits  the  user’s 
credentials  to  the  BIG-IP  automated  data  controller  platform  for  verification  and 
authentication.  Once  the  log-in  and  authentication  processes  are  complete,  CAT  grants 
the  user  access  to  the  system.  Figure  25  provides  the  action  diagram  with  the  data  flow 
that  models  the  user  log-in  process. 
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Figure  24.  Functional  Decomposition  of  F.  1 


Figure  25.  F.l  Action  Diagram 


2.  Performance  Competency  Administration  [F.2] 

Five  sub-functions  decompose  the  F.2  function,  “Perform  Competency 
Administration”  (Figure  26).  As  CAT  grants  the  user  system  access  in  function  F.l. 4,  the 
CAT  system  uses  BIG-IP’ s  user  authentication  and  the  user’s  CAC  credentials  to  access 
and  load  user  specific  data  from  the  CAT  database.  The  system  retrieves  the 
individualized  user  profile  and  the  accompanying  CAT  settings  that  the  data  storage 
function  (F.4)  links  to  the  user’s  credentials.  This  user  profile  specifies  the  appropriate 
GUI  function  from  F.2. 3,  which  can  include  either  the  BFM,  PM,  BH,  or  SL  dashboards. 
The  user  can  then  access  the  required  project  monitoring  functions  via  the  GUI  display. 
The  main  project  monitoring  functions  include  people-to-project  tracking,  schedule 
tracking,  funding  tracking,  and  obstacle  management. 
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The  last  two  F.2  sub-functions  relate  to  user  options  within  CAT.  Function  F.2.4 
allows  for  creating  a  new  profile  or  editing  an  existing  profile’s  preference  settings. 
Function  F.2. 5  allows  the  user  to  save  and  export  CAT  data  in  one  of  four  formats: 
Microsoft  PowerPoint  (*.pptx)  file,  Excel  (*.xlsx)  file,  CAT  (*.cat)  file  (useful  for 
sending  to  another  user  or  archiving  data)  or  exporting  to  a  printer.  Figure  27  shows  the 
action  diagram  with  user  requests  and  data  flow  amongst  the  sub-functions. 
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Functional  Decomposition  of  F.2 
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Figure  27.  F.2  Action  Diagram 


3.  Perform  Session  Termination  [F.3] 

F.3  encompasses  the  functions  to  terminate  a  user  session  and  to  log-out  of  CAT. 
Figure  28  displays  the  F.3  functional  decomposition.  The  first  two  sub-functions  include 
the  two  options  to  accomplish  session  termination:  user-initiated  exit  or  session  time-out. 
In  a  user-initiated  exit,  the  user  would  make  the  deliberate  decision  to  end  the  CAT 
session  and  take  the  steps  to  log-out  of  the  system.  If  CAT  determines  that  the  user  made 
changes  since  the  last  save,  CAT  sends  a  save  prompt  (function  F.3. 5)  and  saves  user  data 
(function  F.3. 6).  In  session  time-out,  CAT  initiates  closure  of  the  user  session  after  a 
period  of  inactivity  and  automatically  saves  use  data  (function  F.3. 6).  CAT  logs  the  user 
off,  thereby  terminating  the  session  (function  F.3. 7).  The  action  diagram  in  Figure  29 
shows  the  data  flow  and  logic  of  each  sub-function’s  contribution  to  user  session 
termination. 
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Figure  28.  Functional  Decomposition  of  F.3 


Figure  29.  F.3  Action  Diagram 


4.  Perform  Data  Storage  Operations  [F.4] 

The  F.4  “Perform  Data  Storage  Operations”  function,  illustrated  in  Figure  30, 
consists  of  six  sub-functions.  During  use  of  the  system,  users  need  CAT  to  accept  data 
storage  requests  (function  F.4.1),  including  compiled  spend  plans,  people  to  project 
associations,  and  new  project  creations.  CAT  must  be  able  to  store  the  information  that 
the  users  create  and  edit  and  make  it  available  for  subsequent  sessions.  CAT  must  accept 
the  data  storage  request  and  perform  function  F.4. 2,  Store  Data,  to  ensure  this  is  the  case. 
At  future  log-ins,  CAT  accepts  data  requests  (function  F.4. 3),  retrieves  the  stored  data 
(function  F.4. 5)  from  CAT  memory,  and  retrieves  and  saves  information  from  the 
interfaced  ERP  database.  CAT  then  sends  the  data  (function  F.4. 4)  to  the  GUI  in  a 
useable  format.  Function  F.4. 5  is  also  responsible  for  retrieving  user  profile  data  and 
user-specific  dashboard  when  a  user  initiates  a  session.  Finally,  CAT  provides  file  upload 
functionality  (function  F.4. 6)  to  import  information  into  CAT  from  outside,  un-interfaced 
sources,  as  needed.  This  functionality  exists  as  a  temporary  solution,  in  the  event  that  live 
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connections  cannot  be  immediately  setup  with  the  external  databases.  Figure  31 
illustrates  the  data  and  functional  flow. 


Figure  30.  Functional  Decomposition  of  F.4 
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Figure  31.  F.4  Action  Diagram 
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B.  MODELING  OF  PERSONNEL  ALLOCATION  AND  FUNDING 

CALCULATION  FUNCTIONALITY 

Team  CAT  accounted  for  the  requirements  to  display  the  personnel  assigned  to 
each  project,  display  worker  utilization  data,  and  create  funding  graphs  for  certain  users’ 
dashboards  in  the  functional  architecture.  Team  CAT  created  a  sample  people-to-project 
execution  chart  to  verify  that  none  of  the  relevant  requirements  or  functions  were  missed, 
and  that  the  calculations  CAT  had  to  perform  were  well  understood.  By  using  the 
informal  Excel  spreadsheet  products  to  instantiate  an  example  of  people-to-project 
allocation  calculations  and  funding  execution  calculations,  Team  CAT  was  able  to  better 
understand  the  functionality  that  the  stakeholders  required  of  the  aforementioned  CAT 
features,  as  well  as  the  data  transformation  and  functional  flow  that  the  architecture 
would  need  to  specify  for  CAT  development.  Screenshots  of  the  Excel  spreadsheets  are 
included  in  Appendix  J. 

A.  FUNCTIONAL  ANALYSIS  WITH  REQUIREMENTS  TRACEABILITY 

MATRIX 

Requirements  traceability  is  a  requirements  analysis  method  that  measures  the 
degree  to  which  system  requirements  can  be  linked  to  system  functions.  The  purpose  of 
requirements  traceability  is  to  ensure  that  the  planned  system  functions  are  sufficient  to 
meet  all  of  the  requirements,  and  that  there  are  no  superfluous  functions  that  are  not 
mandated  by  a  requirement.  At  this  point  in  the  process,  Team  CAT  had  developed  the 
requirements  presented  in  Chapter  III  and  established  the  functions  discussed  in  Chapter 
IV,  Section  A.  As  the  team  developed  the  functional  architecture,  they  used  a  specific 
feature  in  Innoslate  to  automatically  map  the  requirements  to  the  appropriate  functions 
and  export  the  results  to  Microsoft  Excel.  The  product,  known  as  the  Requirements 
Traceability  Matrix  (RTM),  consisted  of  a  single  spreadsheet  that  captured  the  correlation 
in  the  many-to-many  relationship  between  requirements  and  functions.  As  the  Excel  file 
was  well  over  500  lines  long,  use  of  Innoslate  undoubtedly  saved  the  team  much  time  and 
energy,  while  ensuring  accuracy  based  on  previous  functional  architecture  inputs. 

The  auto-generated  RTM  also  increased  the  number  of  requirement-to-function 
tracing  iterations  that  could  be  accomplished.  After  the  first  RTM  iteration,  Team  CAT 
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realized  there  were  some  orphan  functions  that  did  not  trace  back  to  any  parent 
requirements.  The  team  added  the  missing  derived  requirements,  and  the  next  RTM  made 
clear  the  need  for  additional  functions  to  support  the  additional  derived  requirements.  The 
relative  ease  of  creating  new  RTMs  in  Innoslate,  the  ease  of  verifying  functions  to 
requirements  traces  with  the  RTM,  and  the  resultant  iterative  nature  of  requirements  and 
functions  tracing  ultimately  resulted  in  a  more  complete  model  and  a  better  overall 
product  than  would  otherwise  have  been  feasible  without  access  to  these  tools.  The 
improvements  effected  by  this  iteration  illustrate  the  obvious  benefit  of  adherence  to 
MBSE  best  practices.  The  following  paragraph  provides  an  example  of  the  RTM  output 
for  one  specific  requirement,  while  Appendix  H  contains  the  complete  RTM. 

The  first  parent  requirement,  R.l,  contains  all  user  profile  requirements.  It  is 
decomposed  by  the  requirement  to  save  user  data  (i.e.,  requirement  R.l. 1.1).  This 
requirement  captures  the  need  for  CAT  to  be  able  to  save  input  data  from  a  user  during  a 
session.  As  can  be  seen  in  Figure  32,  R.l.  1.1  traces  to  several  sub-functions,  as  well  as  to 
a  main  parent  function.  The  subfunctions  F.2.2.16,  F.2.2.10,  F.2.2.7,  and  F.2.2.4  accept 
and  save  the  input  data  for  the  BFM,  PM,  BH,  and  SF  user  profiles,  respectively.  F.2.4.5, 
as  a  sub-function  of  the  F.2.4  function  to  manage  user  profiles,  generalizes  the  function 
“Accept  User  Input  from  GUI  Module,”  to  ensure  that  each  user’s  data  is  associated  to, 
and  stored  under,  his  or  her  individual  profile.  Fastly,  Team  CAT  traced  the  parent 
function  F.4,  “Perform  Data  Storage  Operations,”  and  its  sub-functions  F.4.2,  F.4.3,  and 
F.4.5  to  the  requirement  to  “save  user  data.”  Although  the  example  in  the  paragraph  is  not 
expanded  and  discussed  in  full  detail,  Team  CAT  did  confirm  that  at  least  one  function 
was  traced  to  every  requirement  and  at  least  one  requirement  was  traced  to  every 
function. 
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Requirements 

Traced  to  I 

Number 

Name 

llfiSffiffiBIIlI 

Number 

Name 

R.  1.1. 1 

Save  user  data 

The  CAT  system 
shall  be  capable 
of  accepting  the 
input  request  to 
save  data. 

F.2.2.4 

Accept  Senior  Leadership  Input  From  GUI 

F.2.2.7 

Accept  BH  Input  from  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

F.4 

Perform  Data  Storage  Operations 

F.4.2 

Store  Data 

F.4.3 

Accept  Requests  for  Data 

F.4.5 

Retrieve  Data 

Figure  32.  RTM  Excerpt  for  “Save  User  Data”  Requirement 


B.  CHAPTER  SUMMARY 

This  chapter  explains  the  processes  Team  CAT  used  to  develop  the  CAT 
functional  architecture.  Section  A  presented  the  functional  architecture  itself,  which 
consisted  of  two  parts:  the  functional  decomposition  and  the  action  diagrams.  The  first 
step  employed  to  create  the  functional  decomposition  was  to  identify,  define  and 
logically  organize  the  functions  required  to  achieve  each  CAT  requirement.  The  overall 
function  of  the  CAT  system  breaks  down  into  the  performance  of  four  main  sub¬ 
functions:  sign-on,  competency  administration,  session  termination  and  data  storage. 
Team  CAT  then  further  divided  these  first-level  functions  into  successively  more  detailed 
sub-functions  to  complete  the  system’s  functional  decomposition.  For  the  second  part  of 
the  functional  architecture,  Team  CAT  used  the  organization  of  the  sub-functions  to 
create  action  diagrams.  The  main  purpose  of  the  action  diagrams  was  to  model  the  flow 
of  data  through  the  system. 

Section  B  provided  a  description  of  spreadsheet  modeling  for  people-to-project 
allocation  and  funding  execution  calculations.  Team  CAT  deemed  modeling  of  these  two 
CAT  functions  essential  to  better  understand  both  the  stakeholder  needs  and  the  data 
transformation  required  for  the  calculations  within  CAT  to  meet  those  needs.  Section  C 
presented  the  RTM,  a  critical  part  of  the  functional  analysis,  which  Team  CAT  used  to 
verify  completion  of  the  requirements  to  functions  traceability.  The  next  chapter 
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discusses  how  the  SE  artifacts  presented  up  to  this  point  helped  create  GUI  dashboards 
that  bridged  the  gap  between  the  SE  documentation  and  the  stakeholders’  needs. 
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V.  GRAPHICAL  USER  INTERFACE  DEVELOPMENT 


One  of  the  primary  focuses  of  this  project  was  to  define  the  way  project  funding, 
schedule,  status,  and  personnel  information  would  be  displayed  to  the  user.  The  different 
capabilities  requested  by  the  stakeholders  (BFM,  PM,  BH,  SL)  led  Team  CAT  to  design 
four  separate  user  dashboards,  one  for  each  user  type.  This  design  approach  provided 
flexibility  to  satisfy  the  needs  of  each  user  type  and  allowed  for  a  streamlined  design, 
where  users  would  only  see  the  data  they  needed  to  perform  their  duties. 

Team  CAT  developed  the  four  GUIs  by  following  the  CAT  SE  products  described 
in  Chapters  II,  III,  and  IV.  To  make  the  dashboards  intuitive  and  easy  to  use  for  the  users, 
Team  CAT  researched  and  applied  human  systems  integration  (HSI)  best  practices, 
described  in  detail  later  in  this  chapter.  Once  Team  CAT  established  the  initial  GUI 
prototype,  the  team  was  able  to  use  that  prototype  to  facilitate  the  elicitation  of  valuable 
feedback  from  stakeholders.  This  stakeholder  feedback  was  critical  to  the  process  of  fine- 
tuning  the  design  for  each  successive  iteration  of  the  GUI. 

Team  CAT  followed  the  UP  iterative  process  to  obtain  frequent  stakeholder 
feedback  using  increasingly  refined  GUI  prototypes.  This  allowed  Team  CAT  to  continue 
to  engage  in  a  process  of  rapid  and  continuous  product  improvement  that  delivered 
increased  value  to  the  stakeholders.  Positive  feedback  from  stakeholders  served  as 
validation  of  GUI  design  decisions,  and  any  recommendations  provided  further  design 
direction  in  the  iterative  GUI  development  process. 

Section  A  summarizes  the  HSI  best  practices  that  Team  CAT  followed  to  support 
GUI  development.  Section  B  provides  an  overview  of  the  evolution  of  the  GUI  as  it  was 
iteratively  refined.  Sections  C  and  D  describe  the  stakeholder  feedback  and  design 
direction  post  IPR  1  and  IPR  2  respectively.  Finally,  Section  E  is  a  detailed  description  of 
the  features  and  components  of  the  final  GUI  design. 

A.  HSI  DASHBOARD  DEVELOPMENT  BEST  PRACTICES 

Since  CAT’s  initial  intended  users  are  NAVAIR  personnel,  Team  CAT  strove  to 

ensure  that  the  design  of  the  GUI  followed  the  appropriate  DOD  guidance.  Department  of 
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Defense  Instruction  (DODI)  5000.02,  which  governs  defense  acquisition,  requires  the 
consideration  of  HSI  during  program  development:  “The  goal  will  be  to  optimize  total 
system  performance  and  total  ownership  costs,  while  ensuring  that  the  system  is 
designed,  operated,  and  maintained  to  effectively  provide  the  user  with  the  ability  to 
complete  their  mission  (Under  Secretary  of  Defense  (AT&L)  2015,  118).” 

Human  Systems  Integration  is  a  crucial  component  of  the  defense  acquisition 
process  because  military  systems  are  dependent  on  operators  who  often  use  the 
equipment  for  long  periods,  in  adverse  environmental  conditions,  or  in  hostile 
environments.  Thus,  the  system  must  be  designed  to  best  fit  the  operator  for  safety  and 
optimal  performance.  The  DODI  further  specifies:  “System  designs  will  minimize  or 
eliminate  system  characteristics  that  require  excessive  cognitive,  physical,  or  sensory 
skills;  entail  extensive  training  or  workload-intensive  tasks;  result  in  mission-critical 
errors;  or  produce  safety  or  health  hazards”  (Under  Secretary  of  Defense  (AT&L)  2015, 
118).  It  is  thus  incumbent  on  system  designers,  engineers,  and  managers  to  ensure  that 
the  system  is  developed  to  best  serve  the  intended  operators,  while  using  taxpayer  dollars 
effectively  throughout  the  life  of  the  system. 

The  DOD  uses  many  diverse  GUIs  to  accomplish  a  wide  range  of  missions.  The 
parent  systems  are  often  mission-critical,  and  their  misuse  has  the  potential  to  cause 
major  equipment  damage  or  catastrophic  loss  of  life.  The  GUI  acts  as  a  force-multiplier 
and  enables  the  operator  to  better  achieve  the  mission,  but  the  system  is  only  as  good  as 
its  interface.  In  their  2013  usability  study  of  U.S.  Army  GUIs,  Abrams,  Dooley  and 
Saboo  (2013)  note: 

While  GUIs  are  designed  to  optimize  system  functionality,  efficiency  of 
software  code,  and  information  assurance,  their  usability...  is  often 
overlooked  until  too  late  in  acquisition  to  make  the  design  changes 
necessary  to  address  deficiencies.  Training  is  then  proposed  as 
remediation  for  usability  problems,  but  when  GUIs  are  poorly  designed, 
training  may  not  be  effective.  (44) 

The  lesson,  then,  is  to  incorporate  user  values  into  the  design  from  the  start  and  to  allow 
ample  time  for  iterative  refinement,  usability  assessment,  and  end-user  testing.  For  the 
CAT  development,  the  team  captured  user  values  during  stakeholder  interviews  and 
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reinforced  them  during  the  IPRs.  The  knowledge  gained  from  the  prospective  users 
helped  inform  the  development  team  of  the  qualities  and  capabilities  that  the  user  found 
most  desirable. 

Although  CAT  is  not  for  use  in  hostile  or  hazardous  environments,  it  remains 
crucial  that  the  system  interface  support  quick  and  easy  user  initiation,  familiarization, 
and  navigation.  To  achieve  such  a  design  requires  a  high  level  of  usability.  The  five 
components  of  computer  usability  are  defined  as  follows:  time  to  learn,  performance 
speed,  user  error  rate,  subjective  user  satisfaction,  and  retention  over  time  (Shneiderman 
1998,  15).  Inclusion  of  these  components  results  in  a  design  that  is  intuitive  and  takes 
advantage  of  established  symbols  and  content  organization.  As  a  result,  the  user  does  not 
have  to  be  taught  how  to  use  the  interface,  nor  does  he  need  to  spend  very  long 
familiarizing  himself  with  the  tool’s  functionality.  The  goal  of  the  design  is  for  the  user 
interface  to  remain  unnoticed,  since  it  should  work  seamlessly  with  the  user’s  existing 
experience. 

While  users  of  any  online  system  must  be  proficient  in  basic  computer  knowledge 
(e.g.,  use  of  a  mouse,  scrolling,  manipulating  menus,  activating  buttons,  and  properly 
interpreting  symbols),  there  are  specific  GUI  design  characteristics  that  best  enable  the 
user  to  accomplish  his  or  her  task  (Gibfried  2005,  20).  To  that  end,  Team  CAT 
researched  recommendations  and  best  practices  for  developing  an  effective  and  highly 
usable  GUI.  From  this  research,  Team  CAT  incorporated  two  important  suggestions  for 
effective  user  interface  design.  The  first  was  the  selection  of  a  common  layout  that  was 
used  consistently  throughout  the  tool  (Mooshage,  Thun  and  Schweingruber  2006,  7).  A 
quad-type  layout  worked  equally  well  for  the  PM,  BH  and  SL  dashboards;  however,  the 
unique  qualities  of  the  BFM  role  necessitated  a  separately-designed  interface.  The  team 
intended  to  use  a  common  design  wherever  possible  to  keep  the  user  experience  similar 
among  user  roles.  This  approach  resulted  in  improved  communication  and  easier  job 
transitions  when  promoting  leads  or  managers  to  higher  roles. 

The  second  suggestion  that  Team  CAT  incorporated  was  the  use  of  only 

frequently-used  and  task-critical  data  in  the  top-level  dashboard  view  (Lulue,  Kammerer 

and  Croft  2009,  11).  As  such,  each  PM,  BH,  and  SL  dashboard  contained  a  quad-style 

63 


design,  supplemented  with  a  schedule  at  the  bottom.  The  system  defaults  to  an  overview 
of  the  user’s  purview,  but  the  user  can  easily  increase  the  level  of  detail  by  selecting  a 
project  or  branch  to  expand  for  more  information. 

1.  Specific  Principles  Driving  User  Dashboard  Design 

Since  a  variety  of  users  with  differing  management  roles  and  responsibilities  will 
utilize  CAT,  the  team  decided  the  best  approach  was  for  CAT  to  have  a  separate,  custom 
dashboard  display  for  each  user  type.  In  this  instance,  a  dashboard  is  a  data  visualization 
tool  that  consolidates  and  presents  the  information  that  is  most  valuable  to  a  particular 
user.  The  dashboard  is  the  first  screen  presented  to  the  user  upon  successful  log-in  to  the 
system.  According  to  Tableau  Software’s  “Top  5  Best  Practices  for  Creating  Effective 
Dashboards  and  the  7  Mistakes  You  Don’t  Want  to  Make,”  the  ideal  dashboard  is 
objectives-focused,  visual,  interactive,  relevant,  current,  and  accessible  to  its  audience. 
According  to  Tableau,  displayed  metrics  should  be  selected  to  optimize  the  available 
space  and  to  best  suit  the  needs  of  the  user  and  the  objectives  of  the  tool.  An  emphasis  on 
visual  displays  improves  comprehension  over  text,  but  the  graphics  should  be  well- 
designed  and  chosen  carefully  to  match  organizational  objectives  (Tableau  Software 
2016). 

Team  CAT  incorporated  these  recommendations  and  best  practices  into  the  design 
and  architecture  of  each  dashboard.  In  particular,  the  team  selected  the  most  meaningful 
metrics  and  graphics  for  each  user,  based  on  stakeholder  inputs,  and  designed  the 
dashboards  to  be  interactive  for  the  highest  degree  of  customization  possible.  The  user- 
centered  customizations  included: 

•  Setting  simple  graphs  and  charts  as  the  focal  point  of  each  dashboard 

•  Allowing  users  the  ability  to  interact  directly  with  charts  and  timelines 

•  Requiring  financial  data  to  be  pulled  daily  from  databases 

•  Designing  the  system  to  be  web-accessible  by  the  user 

Team  CAT  also  accounted  for  the  users’  prior  experience  to  ensure  the  best 
possible  GUI  experience.  For  the  BFM,  whose  role  and  responsibilities  differ 

significantly  from  those  of  other  user  types,  Team  CAT  designed  the  dashboard  to 
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incorporate  the  Longsheet.  Since  the  BFMs  already  used  that  format,  they  were 
comfortable  with  it,  and  it  worked  well. 

2.  Incorporating  User-Centered  Design  Principles  and  Wireframe 
Diagrams 

Another  way  to  improve  design  effectiveness  from  a  usability  standpoint  is  by 
following  user-centered  design  (UCD)  principles.  According  to  the  U.S.  Department  of 
Health  and  Human  Services’  UCD  Basics,  UCD  is  a  framework  in  which  the  knowledge 
of  users,  their  tasks,  their  needs,  their  preferences,  and  their  limitations  is  used  to  create  a 
design  with  the  best  user  experience.  The  iterative  process  has  four  steps:  Context, 
Requirements,  Design,  and  Evaluation.  In  the  first  step,  the  UCD  team  defines  the 
context  of  the  user  population,  as  well  as  the  functions  and  conditions  under  which  each 
user  will  use  the  product.  Next,  the  team  identifies  the  requirements  for  success  and 
constructs  design  solutions.  Finally,  the  design  is  evaluated  by  a  sample  of  actual  users 
(U.S.  Department  of  Health  &  Human  Services  2016). 

A  standard  UCD  best  practice  is  to  use  wireframe  models.  These  models  are  an 
inexpensive  way  to  provide  a  tangible  product  to  users.  Since  development  is  cheap  and 
the  design  remains  easy  to  change,  the  practice  supports  iteration  (Lulue,  Kammerer  and 
Croft  2009,  17).  Furthermore,  since  iteration  with  the  UP  was  a  central  tenant  of  Team 
CAT’s  approach,  development  of  the  GUI  design  using  UCD  followed  naturally. 

Beyond  designing  for  users  and  their  tasks,  the  most  important  principles  of  UCD 
are  clarity  and  consistency  in  the  user’s  actions  to  interface  with  the  system  (U.S. 
Department  of  Health  &  Human  Services  2016).  For  example,  CAT  maintains  a  fixed 
routine  of  drop-down  boxes  to  select  projects,  programs,  or  departments  and  consistently 
uses  check  boxes  to  filter  events  on  schedules. 

Team  CAT  also  included  Usability  Net’s  UCD  recommendation  to  use  simple  and 
natural  dialogue  (Usability  Net  2016)  by  including  the  status  item  “stoplight  chart,” 
discussed  in  the  GUI  development  sections  below.  The  team  modified  the  name  of  the 
chart  from  “Obstacles”  to  “Status”  to  capture  the  nature  of  the  display  and  the  language 
used  by  the  stakeholders  more  accurately  and  simply.  In  addition,  Usability  Net 
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recommends  arranging  the  components  of  the  interface  to  discriminate  the  required 
information  using  a  consistent  presentation  with  the  proper  level  of  detail.  Team  CAT 
captured  this  advice  in  the  dashboards  by  using  overviews  with  the  ability  to  view  more 
detailed  organization  information  as  desired. 

3.  Incorporating  Morville’s  User  Experience 

Although  all  of  the  previously  discussed  best  practices  are  helpful,  they  do  not 
provide  an  adequate  “big  picture”  of  how  the  components  of  GUI  design  relate  to  each 
other.  Team  CAT  decided  to  incorporate  several  of  the  philosophies  of  Information 
Architect  Peter  Morville  to  help  bridge  the  gap.  Morville’s  User  Experience  Design  (UX) 
describes  the  architecture  of  the  user-based  design  as  the  balance  between  “business  goals 
and  context,  user  needs  and  behavior,  and  content”  (Morville  2016a).  Figure  33  illustrates 
this  relationship  between  the  three  main  components. 


Figure  33.  Morville’s  User  Experience  Information  Architecture 

In  a  comment  on  his  blog  “Interwingled,”  Morville  argues  that  “usability  is 
necessary  but  not  sufficient”  (Morville  2016a).  Usability  is  a  key  ingredient  in  a 
successful  interface,  but  it  is  only  part  of  the  solution,  so  designers  should  view  user 
interaction  with  a  system  through  a  wider  lens.  He  takes  UX  a  step  further  in  his  “user 
experience  honeycomb,”  seen  in  Figure  34,  to  enumerate  the  crucial  qualities  that  define 
user  experience. 
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Figure  34.  Morville’s  User  Experience  Honeycomb.  Adapted  from  Morville  (2016b). 

The  expectation  is  that  system  architects  who  consider  these  characteristics  during 
the  design  phase  will  produce  a  GUI  that  is  best  adapted  to  suit  the  needs  of  its  user 
community.  Team  CAT  used  these  seven  adjectives,  with  an  emphasis  on  value,  to  guide 
the  architecture,  efforts  which  ultimately  resulted  in  a  successful,  user-centric  GUI  that 
fulfilled  the  stakeholders’  needs. 

As  previously  mentioned,  through  effective  use  of  the  described  HSI  design 
principles,  as  well  as  through  frequent  elicitation  of  stakeholder  feedback,  Team  CAT 
was  able  to  ensure  that  the  final  GUI  design  was  familiar,  intuitive,  and  easy  to  use.  The 
team  was  able  to  develop  a  comprehensive,  yet  uncluttered,  visual  representation  of  the 
project  metrics  of  interest  for  each  user  type.  The  following  sections  describe  each  stage 
the  team  progressed  through  during  development  of  the  GUI  prototype  design,  before 
ultimately  achieving  the  final  design. 

B.  PROTOTYPE  GUI  EVOLUTION  IN  ITERATION  1  (PRE-IPR  1) 

Team  CAT  began  developing  the  GUI  prototype  by  drawing  simple  shapes  in 
Microsoft  PowerPoint  to  represent  what  should  be  displayed  to  the  user  based  on  the 
initial  decomposition  of  stakeholder  needs.  The  simple  outlines  in  Figures  35  and  36 
helped  Team  CAT  understand  how  the  parent-level  requirements  related  to  what  each 
user  type  needed  to  see.  As  mentioned  in  the  previous  section,  Team  CAT’s  design 
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approach  included  developing  and  tailoring  different  dashboards  for  each  user  type,  even 
in  the  early  stages  of  GUI  conceptualization. 
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Overview  Stoplight  Chart 
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Profile  Type 
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Figure  35.  Initial  GUI  Prototype  Using  Microsoft  PowerPoint  -  Senior  Leadership 

Dashboard 
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Figure  36.  Initial  GUI  Prototype  Using  Microsoft  PowerPoint  -  Project  Manager 

Dashboard 
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During  initial  design  meetings,  the  team  relied  on  the  user-centric  design  best 
practice  of  utilizing  hand-drawn  wireframe  models,  like  the  ones  shown  in  Figure  37. 
Wireframe  models  were  fast  and  easy  to  produce,  and  they  allowed  Team  CAT  to  explore 
the  different  ideas  for  how  to  design  the  dashboards.  The  focus  of  the  wireframe 
diagrams  was  to  explore  design  decisions  on  how  to  best  lay  out  the  dashboard  views,  as 
well  as  what  specific  elements  would  be  used  to  fulfill  stakeholder  requirements.  For 
example,  from  the  requirements  and  architecture  views,  Team  CAT  knew  that  the 
stakeholders  needed  some  way  of  comparing  actual  versus  planned  expenditures.  It  was 
not  until  the  exploration  of  wireframe  diagrams  that  Team  CAT  determined  how  the 
comparison  of  actual  versus  planned  expenditures  would  appear  to  the  users.  By  using 
hand-drawings,  Team  CAT  was  able  to  quickly  draft  and  change  the  GUI  as  necessary  to 
best  meet  the  stakeholders’  needs. 

In  these  hand-made  drafts,  some  of  the  final  design  elements  begin  to  take  shape: 

•  The  PM,  BH,  and  SL  dashboards  began  including  the  project  cost,  status,  and 
schedule  charts  that  the  competency  is  accustomed  to  seeing. 

•  The  BFM  dashboard  took  the  format  of  the  Longsheets  that  the  BFMs  are 
accustomed  to  using. 

•  The  team  included  the  ability  to  filter  data  by  date  or  type. 

•  The  team  included  the  use  of  visual  alert  cues  for  new  or  updated  information. 

Figure  37  illustrates  the  first  set  of  wireframe  models  developed  by  Team  CAT. 
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Figure  37.  Hand- Drawn  CAT  Wireframe  Models 
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These  hand-drawn  wireframe  models  continued  to  be  improved  and  refined  in  an 
iterative  fashion  until  achieving  a  higher  level  of  maturity  as  can  be  seen  in  the  hand- 
drawn  wireframe  SL  dashboard  shown  in  Figure  38.  The  dashboard  in  this  figure  shows  a 
modified  quad-chart  format,  which  the  Team  adjusted  and  refined  before  confirming  the 
design.  The  dashboard  also  includes  the  idea  of  a  “stoplight”  chart  that  displays  project- 
related  status  items  with  a  corresponding  stoplight  color  (red,  yellow,  green)  for  a  quick 
overview,  a  personnel  tracking  chart,  and  a  rough  outline  of  a  finances  chart. 


Figure  38.  Wireframe  Senior  Leadership  Dashboard 
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After  several  rounds  of  creating  hand-drawn  wireframe  diagrams  to  refine  the 
GUI,  the  prototype  design  had  matured  enough  to  warrant  investing  resources  to  create  a 
clean  version  that  could  be  formally  presented  to  the  stakeholders  for  feedback  at  IPR  1 . 
Team  CAT  constructed  this  new  version  as  an  interactive  web-based  prototype, 
illustrated  in  Figure  39.  This  prototype  was  a  much  more  refined  version  of  the  GUI, 
compared  to  the  initial  PowerPoint  prototype  that  served  as  the  GUI  starting  point.  It 
featured  a  header  with  logos,  a  customizable  pre-filtered  timeline,  the  funding 
expenditure  graphics,  and  interactive  drop  down  menus.  Appendix  K  includes  additional 
screenshots  of  the  finalized  prototype  designs. 
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Figure  39.  Partial  Screenshot  of  Senior  Leadership  Dashboard  Overview 
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It  is  important  to  note  that  the  more  refined  web-based  versions  of  the  dashboards 
endured  two  distinct  rounds  of  formal  adjustment  and  refinement  (post-IPR  1  and  post- 
IPR  2)  before  arriving  at  the  final  GUI  design  that  is  fully  described  at  the  end  of  the 
chapter.  Dashboard  layout,  functional  grouping,  color  choice,  spacing,  and  headings  were 
just  some  of  the  design  elements  that  Team  CAT  considered  and  refined. 

In  summary,  prior  to  IPR  1,  Team  CAT  used  the  SE  artifacts  presented  in 
Chapters  II-IV  to  begin  prototyping  the  CAT  GUI.  The  GUI  consisted  of  four 
dashboards,  one  for  each  user  type,  to  provide  each  user  with  the  functionality  needed  to 
be  effective  in  his  or  her  role.  Team  CAT  began  by  using  a  Microsoft  PowerPoint  version 
of  the  GUI  to  lay  out  the  specific  placeholders  of  functionality  that  would  meet  the 
requirements  presented  in  Chapter  III.  Team  CAT  then  used  wireframe  diagrams  to  plan 
quickly  and  easily  how  specific  placeholders  from  the  Microsoft  PowerPoint  version  of 
the  GUI  could  be  populated. 

C.  DESIGN  DIRECTION  IMPLEMENTED  IN  ITERATION  2  (POST-IPR  1) 

IPR  1  represented  the  first  opportunity  to  formally  present  Team  CAT’s  work  and 
receive  substantial  feedback  from  stakeholders.  At  this  point,  Team  CAT  began  to  tailor 
the  design  of  the  product  and  specific  GUI  layouts  to  meet  the  expectations  and 
preferences  of  the  different  user  groups. 

In  some  instances,  the  feedback  received  from  the  stakeholders  helped  to  refine 
high-level  system  behavior,  but  it  also  required  revisiting  and  revising  requirements  and 
functional  architecture  items.  Eventually,  the  changes  would  flow  down  to  the  GUI  level. 
Fortunately,  the  majority  of  design  changes  were  interface  related,  so  Team  CAT  were 
able  to  adopt  the  modifications  without  the  need  to  change  higher  level  SE  artifacts. 
Tables  7-11  contain  representative  examples  of  the  GUI-related  design  direction  received 
from  the  different  stakeholders  at  IPR  1  that  the  team  considered  for  incorporation  into 
later  iterations  of  the  GUI. 
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Table  7.  IPR  1  Design  Feedback  for  BFM  Dashboard 


Design  Direction 
Title 

Design  Direction  Description 

BFM  Dashboard 
Changes 

Add  new  columns  to  fully  match  the  Longsheet  format  and  make  every 
cell  and  field  editable  by  the  users. 

Table  8.  IPR  1  Design  Feedback  for  PM  Dashboard 


Design  Direction 
Title 

Design  Direction  Description 

Spend  Plan 
Changes 

Add  inputs  fields  for  material  cost,  labor  cost,  and  personnel  cost  when 
creating  a  project  spend  plan. 

Funding  Graph 
Changes 

Indicate  the  projected  date  that  all  funds  will  be  expended,  based  on  the 
current  burn  rate.  Allow  the  insertion  of  ‘call-outs’  to  explain  major 
changes  in  the  spend  plan  or  burndown. 

Table  9.  IPR  1  Design  Feedback  for  BH  Dashboard 


Design 

Direction  Title 

Design  Direction  Description 

Personnel 
Tracker  Changes 

Refine  use  of  colors,  make  it  so  that  clicking  on  a  worker  opens  a  window 
with  task  loading  details,  visually  indicate  over-allocated  workers,  show 
what  the  historical/actual  allocation  of  a  worker  on  a  project  has  been. 

Funding  Graph 
Changes 

Allow  the  insertion  of  “call-outs”  to  explain  changes  in  the  spend  plan  or 
burndown. 

Timeline 

Changes 

Allow  changing  the  date  range  and  scrolling  the  timeline. 

Create  New 
Project  Option 

Provide  a  “create  new  project”  button  for  BF1  users  to  be  able  to  create 
new  projects. 
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Table  10.  IPR  1  Design  Feedback  for  SL  Dashboard 


Design  Direction  Title 

Design  Direction  Description 

Status  Item  Sorting  and  Filtering 

Provide  sorting  and  filtering  options  for  list  of  status  items. 

Table  11.  IPR  1  Design  Feedback  for  General  Items  (Not  User-Specific) 


Design 

Direction  Title 

Design  Direction  Description 

User  Settings 
Window 
Changes 

Provide  a  button  for  users  to  be  able  to  change  their  personal  settings,  such 
as  when  he  or  she  should  be  alerted  of  upcoming  schedule  items,  or  over- 
/under-expenditure  of  funding. 

Export  Items 
Option 

Provide  an  export  button  that  allows  for  users  to  print,  save  and  email  a 
“quad-chart  style”  report  for  each  project,  show  major  status  of  the  project 
when  hovering  mouse  over  a  project  name,  when  a  specific  project  is 
selected  provide  a  place  to  record  notes  or  comments  against  a  milestone  or 
deliverable. 

D.  DESIGN  DIRECTION  FOLLOWING  IPR  2 

For  IPR  2,  Team  CAT  presented  the  updated  GUI  dashboards  that  incorporated 
the  functionality  and  design  change  requests  received  during  IPR  1.  The  hands-on  nature 
of  the  interactive  web-based  GUT  along  with  the  live  demonstration  at  IPR  2,  provided 
stakeholders  the  opportunity  to  inspect  the  GUI  and  provide  additional  feedback  to  the 
team.  The  positive  feedback  received  from  the  stakeholders  during  IPR  2  served  as  an 
informal  validation  of  the  GUI  design  decisions.  The  number  of  requests  for 
improvement  and  new  design  direction  received  during  IPR  2  were  minimal,  helping  to 
confirm  the  maturity  of  the  GUI  design.  Table  12  contains  the  list  of  GUI  changes  carried 
forward  from  IPR  2  and  incorporated  into  final  prototype  GUI  design. 
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Table  12.  IPR  2  Design  Feedback  for  General  Items  (Not  User-Specific) 


Design 

Direction  Title 

Design  Direction  Description 

Rename 
Obstacle  to 
Status  Update 

Rename  “obstacle”  list  to  a  “status  update”  list  to  better  reflect  the  intended 
use  of  capturing  both  positive  and  negative  status  items  instead  of  only 
obstacles  or  hindrances. 

Remove  Share 
CON 

Remove  the  “share  CON”  email  button  from  the  GUI  as  this  is  a  future 
work  functionality. 

E.  RECOMMENDED  FINAL  DESIGN 

This  section  describes  the  finalized  dashboards  in  detail  for  each  user  type. 
Appendix  K  contains  additional  screenshots  of  the  finalized  GUI. 

1.  Budget  Financial  Manager  Dashboard 

Team  CAT  designed  the  BFM  dashboard  as  an  interface  that  would  be  familiar  to 
a  BFM  user.  As  such,  the  BFM  dashboard  mimics  the  look  and  feel  of  the  Longsheets, 
which  had  been  the  standard  product  to  track  competency  funding.  As  in  the  Longsheet, 
the  BFM  dashboard  offers  the  convenience  of  capturing  comments  against  any  data  cell, 
time-stamping  those  comments,  and  tracking  each  user’s  comment  history.  Figure  40 
illustrates  the  general  look  of  the  BFM  dashboard,  while  Appendix  K,  Figure  K-2  shows 
a  larger  version  of  the  figure  and  its  details. 
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CAT  •  Competency  Administration  Toolset 


Figure  40.  BFM  Dashboard  Screenshot  from  CAT  Prototype 

2.  PM  Dashboard 

Similar  to  the  BFM  dashboard,  Team  CAT  designed  the  PM  dashboard  as  an 
interface  that  would  be  familiar  to  the  PM  users,  basing  it  on  the  competency’s  quad- 
chart  format  that  presents  project  status.  If  more  than  one  project  has  been  assigned  to  a 
PM,  a  drop-down  menu  in  the  upper  right  allows  selection  of  which  project  to  display. 
Figure  41  illustrates  the  general  look  of  the  PM  dashboard,  while  Appendix  K,  Figure  K- 
3  contains  a  larger  version  of  the  figure  and  its  details. 
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CAT  -  Competency  Administration  Toolset 
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Figure  41.  PM  Dashboard  Screenshot  from  CAT  Prototype 
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Once  a  user  selects  a  project  or  the  first/default  project  is  showing,  the  upper  left 
quadrant  displays  a  list  of  project  status-items  color-coded  to  easily  determine  current 
status.  The  upper  right  quadrant  shows  a  funding  graph  of  planned  expenditures  versus 
actual  expenditures,  as  well  as  a  projection  of  when  funding  is  expected  to  be  fully  used 
up.  The  “Create  Spend  Plan”  button  below  the  graph  allows  users  to  create  and  view  their 
planned  expenditures.  The  lower  left  quadrant  displays  a  list  of  project  schedule  items, 
such  as  milestones  and  deliverables,  with  the  due  date  and  status  of  each.  The  lower  right 
quadrant  displays  a  list  of  the  project’s  chargeable  object  numbers  (CONs),  including 
information  on  the  account’s  balance  and  expiration  dates.  Finally,  below  the  four 
quadrants,  a  project-specific  timeline  provides  a  visual  depiction  of  the  schedule  items. 
The  timeline  is  filterable,  with  color-coded  artifacts  that  visually  show  the  project 
milestones  and  deliverables  in  an  intuitive  manner. 

3.  BH  Dashboard 

The  BH  dashboard  borrows  the  top  two  quadrants  and  the  timeline  from  the  PM 
dashboard;  however,  the  default  view  aggregates  the  data  from  all  of  the  BH’s  assigned 
projects  into  a  single  dashboard,  rather  than  displaying  metrics  from  a  single  project.  For 
example,  the  planned  versus  actual  expenditures  in  the  upper  right  quadrant  are  no  longer 
a  single  project’s  funding  status;  instead,  the  graph  now  represents  an  aggregate  of  all 
projects  under  the  BH’s  authority.  A  BH  can  choose  to  filter  the  data  to  a  single  project 
using  the  top  right  drop-down  menu.  When  a  BH  selects  a  specific  project  to  focus  on, 
CAT  provides  the  user  with  a  project- specific  dashboard  identical  to  the  PM’s  view. 

Another  major  difference  between  the  PM  and  BH  dashboards  is  that  the  BH  is 
presented  with  an  interactive  people-to-project  tracker  that  graphically  presents  the 
allocation  of  the  BH’s  personnel  to  available  projects.  This  people-to-project  tracker 
graph  allows  the  BH  to  identify  actual  or  projected  over-allocation  or  under-allocation  of 
personnel  resources  within  the  branch.  The  “people”  table  in  the  display  (Figure  42) 
shows  the  allocation  of  each  person  at  any  given  time  in  the  fiscal  year.  The  “project” 
table,  on  the  other  hand,  displays  whether  projects  have  assigned  workforce  at  the  level 
needed.  In  more  detailed  views,  the  BH  is  able  to  assign  workers  to  projects  while 
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simultaneously  viewing  their  individual  allocation  during  a  specific  period.  Figure  42 
illustrates  the  general  look  of  the  BH  dashboard,  while  a  larger  version  of  the  figure  and 
its  details  is  in  Appendix  K,  Figure  K-6. 
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CAT  -  Competency  Administration  Toolset 
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Figure  42.  BH  Dashboard  Screenshot  from  CAT  Prototype 
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4. 


SL  Dashboard 


The  SL  dashboard  follows  the  pattern  of  the  PM  and  BH  dashboards;  however, 
the  data  presented  at  the  initial  default  view  for  SL  is  at  a  higher  level  of  abstraction. 
CAT  aggregates  the  data  displayed  in  the  default  SL  dashboard  across  all  of  the  branches 
within  the  competency.  Like  the  BH  dashboard,  users  can  filter  the  SL  dashboard  to 
display  specific  branches  or  projects,  depending  on  the  level  of  detail  desired.  The  filter 
option  is  useful  to  allow  SL  to  focus  on  specific  areas  of  the  competency,  while  the 
default  unfiltered  SL  dashboard  home  screen  presents  a  condensed  snapshot  of  the  overall 
competency  health.  The  default  view  is  intended  to  quickly  convey  the  most  essential 
information  for  decision  making,  per  the  guidance  obtained  from  the  HSI  best  practices 
discussed  in  Chapter  V,  Section  A.  Figure  43  illustrates  the  general  look  of  the 
SL  dashboard,  while  a  larger  version  of  the  figure  and  its  details  is  in  Appendix  K, 
Figure  K-8. 
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CAT  -  Competency  Administration  Toolset 
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Figure  43.  SL  Dashboard  Screenshot  from  CAT  Prototype 
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As  can  be  inferred  from  the  different  dashboard  descriptions,  Team  CAT  provided 
significant  consideration  to  accommodate  each  user’s  specific  data  needs  while  keeping 
the  user  interface  clean  and  uncluttered,  heeding  HSI  design  best  practices.  The 
stakeholder  competency’s  software  development  team  will  use  these  validated  prototype 
dashboards  to  inform  the  development  of  the  working  version  deployed  GUI  and  help 
guide  the  actual  programming  of  the  CAT  functionality. 

F.  CHAPTER  SUMMARY 

One  of  Team  CAT’s  primary  objectives  was  to  find  an  effective  method  of 
displaying  data  to  the  different  user  types.  Chapter  V  summarizes  Team  CAT’s  HSI  best 
practices  research  and  the  multiple  iterations  of  GUI  prototypes  that  informed  the  final 
GUI  design  for  each  four  different  user  types’  dashboards.  Section  A  summarized  those 
HSI  best  practices  that  informed  Team  CAT’s  GUI  design.  Section  B  presented  the  initial 
evolution  of  the  first  conceptual  Microsoft  PowerPoint  GUI  model  to  more  detailed 
wireframe  models  and  the  first  iterations  of  the  pre-IPR  1  web-hosted  GUI.  Section  C 
contained  descriptions  of  the  iterative  refinement  of  the  GUI  based  on  considerable 
stakeholder  feedback  during  IPR  1,  while  Section  D  described  additional,  but  subtler 
changes  from  stakeholder  feedback  and  design  direction  post-IPR  2.  Section  E  provided 
an  in-depth  narrative  and  pictures  of  the  final  GUI  design. 

Ultimately,  Team  CAT  maintained  GUI  design  momentum  through  compliance 
with  the  UP  and  reliance  on  frequent  stakeholder  reaction  to  improve  GUI  prototypes.  By 
incorporating  the  users  within  the  design  process,  Team  CAT  was  able  to  produce  a 
design  that  fulfilled  the  various  stakeholders’  needs,  resulting  in  verbal  validation  from 
all  four  stakeholder  groups. 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


A.  CONCLUSION  AND  FINAL  THOUGHTS 

In  keeping  with  the  initial  goals  and  objectives  of  this  study,  Team  CAT  has 
successfully  performed  the  following:  (i)  designed  a  project  management  system  to  track 
and  manage  the  cost,  schedule,  and  status  of  the  stakeholder  competency’s  unclassified 
projects,  (ii)  developed  a  system  architecture  to  trace  stakeholder  needs  down  to  specific 
system  functionality,  and  (iii)  developed  a  prototype  GUI  as  a  proof  of  concept  for  the 
system  functionality.  Evident  through  this  report,  all  objectives  have  been  met. 
Confirmation  from  all  levels  of  the  stakeholder  representatives  indicated  that  Team  CAT 
successfully  met  the  project’s  objectives  stated  in  Chapter  I.  Based  on  the  stakeholders’ 
responses  and  enthusiasm  for  the  design,  the  team  anticipates  the  system  will  meet  the 
needs  of  stakeholders  once  it  is  developed.  The  fact  that  CAT  will  have  the  capability  to 
calculate  and  compile  critical  project  information,  then  generate  graphs  and  reports  from 
that  information,  will  allow  management  to  make  better-informed,  data-driven  decisions. 

Once  the  system  has  proven  successful  within  the  stakeholder  competency,  CAT 
has  the  potential  to  grow  and  support  other  NAVAIR  competencies.  Furthermore,  CAT 
could  eventually  extend  to  support  other  non-NAVAIR,  DOD  organizations  as  well,  if 
source-data  dependencies,  such  as  dependencies  on  NERP  financial  data,  were  either 
changed  or  expanded  upon.  Overall,  with  the  numerous  tools  that  the  government  adapts, 
CAT  can  serve  as  a  single  tool  to  bind  concepts  together — benefiting  other  areas  of  the 
project  management  process  and  eventually  the  Naval  Aviation  Enterprise. 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

The  following  section  will  briefly  discuss  areas  in  which  there  may  be  potential 
for  future  work,  specifically  relating  to  the  system’s  non-functional  requirements  and 
capability  enhancements. 
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1.  Exploring  Non-functional  Requirements 

Team  CAT  recommends  that  future  development  teams  perform  further  research 
on  the  system-wide  non-functional  requirements  discussed  in  Chapter  III.  This  project 
focused  on  the  functional  design  of  the  CAT  system,  but  the  non-functional  areas  of 
compatibility,  usability,  security,  reliability,  availability,  maintainability,  sustainability, 
and  affordability  are  also  critical  for  the  system  to  be  suitable  to  the  users.  By  obtaining  a 
high  level  of  detail  in  these  non-functional  areas,  the  future  software  development  will  (i) 
ensure  that  CAT  is  compatible  with  the  current  IT  infrastructure,  (ii)  maintain  the 
system’s  intuitive  nature  and  ease  of  use,  and  (iii)  ensure  the  system’s  ability  to  protect 
sensitive  information.  The  following  paragraphs  describe  the  team’s  recommendations 
for  future  work  with  regard  to  reliability,  availability,  maintainability,  sustainability,  and 
affordability. 


a.  Reliability 

Unlike  hardware  reliability,  software  reliability  is  not  a  function  of  time.  Software 
does  not  wear  out  or  age  like  the  physical  faults  found  in  hardware,  but  rather  software 
reliability  is  a  function  of  software  design.  Reliability  issues  that  need  to  be  avoided  early 
in  the  software  development  process  are  typically  due  to  specification  misinterpretations 
and  ambiguities.  Knowing  these  risks.  Team  CAT  worked  to  be  as  thorough  and  clear  as 
possible  in  requirements  definition  and  system  functional  analysis.  Furthermore,  the 
software  development  team  will  also  have  to  ensure  that  their  processes  contribute 
towards  software  reliability. 

b.  Availability 

Team  CAT  recommends  that  future  development  teams  establish  availability 
requirements  to  ensure  the  CAT  software  system  can  be  used  during  times  of  needed 
operation.  At  a  minimum,  these  requirements  should  include  backup  methods  of 
accessing  external  data  and  ensuring  compliance  with  interoperability  constraints. 
Software  maintainability  requirements  are  critical  and  should  include  the  capability  to 
modify  the  software  after  delivery.  This  flexibility  allows  software  maintainers  to 
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continue  to  improve  CAT  performance,  correct  faults,  test  newly  developed  hardware,  or 
adapt  to  future  requirements  as  the  operational  environment  evolves. 

c.  Sustainability 

Team  CAT  recommends  that  future  software  sustainment  requirements  include 
the  processes,  procedures,  people,  materiel,  and  information  needed  to  support  and 
maintain  all  software  aspects  of  the  CAT  system.  Sustainment  requirements  go  beyond 
just  software  “maintenance”  needs  and  should  include  appropriate  levels  of  required 
documentation,  training,  help  desk  support,  and  technology  refresh.  Future  developers 
should  determine  when  the  CAT  system  would  enter  a  sustainment  phase  during  its  life 
cycle  and  what  the  entry  criteria  will  be  to  do  so. 

d.  Affordability 

Lastly,  Team  CAT  recommends  performing  a  cost-benefit  analysis  to  quantify  the 
life-cycle  cost  savings  of  the  CAT  system,  when  compared  to  the  current  process.  The 
future  development  team  should  evaluate  the  CAT  system  to  quantify  the  number  of 
man-hours  saved,  as  well  as  to  define  costly  mistakes  to  avoid  when  implementing  the 
new  system.  The  competency  could  then  use  this  data  to  verify  affordability  requirements 
and  determine  which  software  features  would  reduce  costs  further.  This  data  would  also 
support  the  business  case  for  potentially  expanding  the  system  to  a  NAVAIR  enterprise 
level. 


2.  Future  Expansion 

Developing  the  user  stories  and  use  cases  with  stakeholders  allowed  Team  CAT 
to  document  additional  desired  capabilities  and  features;  however,  the  team  did  not 
explore  these  features  due  to  scope  limitations.  Team  CAT  believes  the  additional 
capability  areas  are  worth  exploring  more  deeply,  when  the  scope  allows.  They  include 
the  following:  additional  connectivity  with  external  IT  systems,  additional  funding 
tracking  features,  and  a  more  robust  personnel  tracking  system. 
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a. 


Connection  to  Microsoft  Office  Applications 


The  stakeholders  expressed  an  interest  to  connect  to  Microsoft  Office  applications 
through  CAT.  For  example,  they  discussed  how  they  may  want  CAT  populate  Microsoft 
Outlook  calendars  of  key  leadership  personnel  with  project  milestones  and  deliverable 
dates.  The  stakeholders  also  expressed  the  need  for  CAT  to  interface  with  Microsoft 
Project  as  well,  to  connect  schedule  items  in  CAT  to  their  projects’  work  breakdown 
structures.  The  expanded  connectivity  features  will  allow  SL  and  BHs  to  have  an 
increased  awareness  of  their  projects  without  always  having  to  directly  log  into  the  CAT 
system. 


b.  Expansion  of  Financial  Tracking  Features 

Expanding  upon  the  financial  tracking  features  can  also  permit  better  funds’ 
management,  specifically  at  the  level  of  SL.  Currently  the  CAT  system  design  only  tracks 
funding  allocated  to  specific  projects.  An  added  capability  for  future  research  is  the 
capability  to  track  competency  overhead  funding  shared  between  competency  resources. 
Specific  overhead  spending  includes  common  materials,  supplies,  and  funding  for  general 
training.  The  added  capability  to  include  overhead  funding  management  opens  the 
aperture  to  larger  scale  management  vice  being  limited  to  the  needs  of  specific  projects. 

c.  Expansion  of  Personnel  Tracking  Features 

SL  and  BHs  have  also  expressed  the  need  for  CAT  to  go  beyond  tracking 

personnel  assigned  to  a  specific  project  and  include  a  means  of  tracking  personnel 

professional  development.  Specifically,  the  stakeholders  have  requested  the  capability  to 

track  personnel  professional  qualifications,  education,  and  time  on  the  job.  Lor  example, 

BH  and  SL  stakeholders  expressed  the  need  to  view  when  specific  personnel  are  due  for 

Defense  Acquisition  Workforce  Improvement  Act  (DAWIA)  certification  in  his  or  her 

primary  career  track  and  what  DAWIA  certifications  he  or  she  have  already  obtained.  By 

connecting  with  the  electronic  Defense  Acquisition  Career  Management  (eDACM) 

database,  which  manages  DAWIA  training  records,  future  development  teams  could 

integrate  this  capability  into  the  CAT  dashboards.  Having  a  convenient  way  to  view  an 

employee’s  prior  education,  expertise,  training,  and  education  information  would  allow 
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BHs  to  assign  the  most  qualified  person  to  a  competency  project.  It  would  also  allow 
them  to  ensure  their  employees  stay  current  with  their  professional  development 
requirements. 

BHs  have  also  indicated  that  improvements  to  employee  timecard  management 
would  be  a  welcome  addition  to  CAT.  Since  CAT’s  recommended  design  includes  the 
capability  to  communicate  with  NERP,  CAT  could  potentially  serve  as  the  primary  tool 
for  managing  personnel  timecards.  With  this  added  capability,  CAT  would  be  able  to 
write  data  back  into  NERP,  instead  of  simply  pulling  and  reading  data.  Using  CAT  as  an 
interface  tool  for  timecard  management  would  allow  the  competency  to  have  greater 
flexibility  to  add  additional  time-management  features,  since  their  own  in-house  software 
development  team  would  be  the  ones  developing  the  interface. 
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APPENDIX  A.  RECOMMENDED  SOFTWARE 
IMPLEMENTATION  STRATEGY 


Team  CAT’s  intent  was  for  this  report,  the  SE  artifacts  created  throughout  the 
project,  and  the  final  prototype  GUI  to  serve  as  a  solid  foundation  for  development  of  a 
more  capable  management  tool  in  the  future.  The  team  hopes  that  this  tool  will  eventually 
be  utilized  not  just  within  the  stakeholder  competency,  but  also  at  the  enterprise  level.  To 
increase  the  likelihood  of  success,  Team  CAT  has  developed  a  potential  implementation 
strategy,  which  will  be  discussed  in  the  following  sections. 

A.  SOFTWARE  DEVELOPMENT  STRATEGY 

The  stakeholder  competency  communicated  that  once  Team  CAT  delivered  the 
SE  artifacts  for  this  project,  the  competency’s  software  development  team  would  use  the 
artifacts  to  create  a  fully  functional  software  system.  The  software  development  team  has 
demonstrated  prior  experience  with  iterative  software  development  life-cycle  processes. 
As  such,  the  software  team  specifically  requested  documentation  of  user  stories  that 
traced  to  the  system  architecture,  so  that  they  may  use  the  products  to  develop  the  system. 
The  software  development  team  plan  to  use  the  prototype  GUI,  displayed  in  Chapter  V 
and  Appendix  K,  to  develop  the  first  iteration  of  the  software.  Furthermore,  although 
Team  CAT  will  have  completed  this  project  by  the  time  CAT  is  actually  being  built, 
Team  CAT’s  Project  Lead  will  maintain  communication  with  the  stakeholder 
competency  to  help  clarify  any  questions  that  might  arise  from  the  software  development 
team  through  the  development  process. 

The  software  development  team  should  also  focus  on  successfully  establishing 
live  connections  to  external  databases  and  complying  with  the  corresponding  security 
measures,  which  they  have  done  for  past  projects  within  the  competency.  Team  CAT, 
along  with  the  software  development  team,  has  determined  that  in  order  to  expedite  the 
process  of  making  CAT  functional,  the  development  team  will  begin  creating  manual 
data  upload  capabilities  to  the  software,  while  they  are  simultaneously  executing  the 
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process  of  obtaining  live  connections  to  the  external  systems.  As  such,  Team  CAT  has 
specified  the  manual  upload  capability  in  the  system  functional  architecture. 

The  process  of  obtaining  live  connections  includes  submitting  paperwork 
describing  the  reason  for  the  automated  data  pulls,  as  well  as  providing  certification  from 
NAVAIR  that  CAT  has  an  authority  to  operate  (ATO)  on  the  NMCI  Non-Secure  Internet 
Protocol  Router  Network  (NIPRNET).  The  stakeholder  competency  has  strategized  that, 
upon  completion  of  CAT’s  first  prototype,  they  will  present  the  CAT  concept  and 
prototype  to  NAVAIR  business  management  leadership.  The  prototype  will  have  the 
capability  for  BFMs  to  manually  upload  the  raw  NERP  and  Commanding  Staffing  data  to 
CAT,  to  demonstrate  the  capabilities  of  the  system.  The  intent  will  be  to  show  that,  if  the 
competency  were  able  to  establish  live  connections,  the  BFMs  would  no  longer  have  to 
manually  download  data  from  the  source  databases  and  upload  to  CAT;  instead,  they 
could  simply  access  the  most  updated  data  from  within  CAT. 

The  competency  has  had  success  with  a  similar  strategy  in  the  past  to  obtain  live 
database  connections.  Having  the  tool  readily  available  to  demonstrate  allows  command 
leadership  to  more  easily  see  the  need  for  a  tool  like  CAT  at  the  enterprise  level.  Team 
CAT  believes  that  the  process  of  obtaining  access  to  live  databases  will  be  much  easier 
after  gaining  NAVAIR  command  leadership  support.  If  successful,  this  strategy  will 
allow  for  expansion  of  CAT  to  a  NAVAIR  enterprise  level. 

B.  SOFTWARE  TESTING  STRATEGY 

To  perform  acceptance  testing  on  the  software,  developers  will  need  to  translate 
the  user  stories  captured  by  Team  CAT  into  pass/fail  criteria.  The  software  development 
team  will  then  create  a  software  test  plan  to  (i)  analyze  the  CAT  software  objectives,  (ii) 
determine  what  tests  are  necessary  to  meet  those  objectives,  and  (iii)  ensure  the  data 
obtained  during  the  tests  will  allow  thorough  completion  of  the  objectives.  The  largest 
portion  of  the  test  plan  would  likely  consist  of  software  interoperability  objectives  and 
constraints,  since  the  CAT  system  will  rely  on  data  from  external  sources  to  operate. 

Software  verification  and  validation  will  be  the  final  stage  of  testing.  This  will 
ensure  that  the  CAT  system  meets  both  the  specifications  and  the  intended  purpose  of  all 
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stakeholders.  The  requirements  generated  from  Team  CAT’s  SE  efforts  will  serve  as 
direct  verification  criteria.  Based  on  verbal  confirmation  by  all  levels  of  stakeholders 
during  IPR  2,  the  team  anticipates  that  software  validation  efforts  will  be  minimal. 

C.  DEPLOYMENT  STRATEGY 

The  stakeholder  competency  has  demonstrated  prior  experience  with  hosting  web 
services  for  use  throughout  the  Navy.  For  the  first  iteration  of  CAT  development,  the 
stakeholder  competency  has  planned  on  hosting  CAT  on  server  space  that  is  already  used 
for  other  web-based  products.  CAT  users  will  be  provided  with  a  .’’navair.navy.mil” 
uniform  resource  locator  (URL)  to  access  CAT.  Team  CAT  anticipates  that,  as  CAT 
development  continues  and  more  data  is  hosted  within  CAT,  the  stakeholder  competency 
will  procure  additional  hosting  services  through  their  current  service  provider. 
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APPENDIX  B.  LIFE-CYCLE  MODELING  LANGUAGE 

ONTOLOGY 


The  following  table  illustrates  the  detailed  Life  cycle  Modeling  Language  (LML) 
ontology  built  into  Innoslate  (LML  Steering  Committee  2016). 
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APPENDIX  C.  STAKEHOLDER  RESEARCH  QUESTIONS 


A.  FOR  BUSINESS  FINANCIAL  MANAGER  (BFM) 

Introduction:  We  are  conducting  a  systems  engineering  analysis  on  the  current 
data  management  processes  used  by  the  BFM  department  to  support  AIR-4. OM  personnel 
and  senior  leadership.  In  particular,  we  are  interested  in  learning  about  user-specific 
information  related  to  the  step-by-step  procedures  used  to  pull  sets  of  data  and  metrics 
from  existing  databases. 

1.  Funding  Data 

a.  How  many  different  databases  do  the  BFMs  interact  with  to  pull 
information  for  funding  data?  What  are  the  names  of  these  databases? 

b.  What  data  products  are  used  from  the  aforementioned  databases? 

c.  How  often  does  the  BFM  department  interact  with  those  databases  to 
pull  information  for  administrative  data? 

d.  How  many  labor  hours  are  required  on  a  weekly  basis  to  collect, 
update,  and  maintain  administrative  data? 

e.  What  are  the  longest,  shortest,  and  average  times  are  on  this  process? 

f.  How  long  does  it  take  to  conduct  the  routine  data  pulls  from  ERP? 

g.  What  are  the  longest,  shortest,  and  average  times  are  on  this  process? 

h.  How  long  does  it  take  to  conduct  any  ad-hoc/specific  data  pulls  from 
ERP? 

i.  What  are  the  longest,  shortest,  and  average  times  are  on  this  process? 

j.  After  pulling  the  data,  how  long  does  it  take  to  process  that  data  into  a 
format  that  could  be  sent  to  leadership? 

k.  What  are  the  longest,  shortest,  and  average  times  are  on  this  process? 

l.  How  often  is  data  updated  for  the  competency? 
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m.  How  often  is  that  updated  data  distributed  to  the  competency? 

n.  Please  describe  the  step-by-step  processes  of  collecting,  processing, 
and  sending  off  the  data. 

o.  How  is  the  data  provided  to  the  competency?  (Ex:  email,  SharePoint, 
printed  reports,  etc.) 

p.  Is  there  a  documented  process  that  the  CAT  team  can  review  to  better 
understand  the  interactions  with  the  external  databases? 

q.  Are  there  examples  of  data  artifacts  that  the  CAT  team  can  review  to 
better  understand  the  data  and  final  data  products? 

r.  Are  there  products  that  that  are  considered  useful  that  your  department 
currently  does  not  use? 

s.  Is  there  any  data  that  needs  to  be  entered  manually  by  a  BFM  since  it 
is  not  available  in  any  other  databases? 

t.  If  so,  how  much  time  does  it  take  to  populate  manual  entries  for  each 
of  your  processes? 

2.  Tools 

a.  What  specific  software  tools  does  the  BFM  department  use  to 
download,  process,  compile,  and  distribute  the  funding  data? 

b.  If  a  tool  existed  to  assist  in  the  administrative  process,  what  are  the 
most  important  attributes  and  characteristics  it  would  need  to  have? 
Examples  may  include:  ease  of  use,  readability  of  output,  flexibility  of 
product,  tailorability,  network  accessibility,  degree  of  automation,  and 
time  to  pull  data  and  generate  the  report? 

c.  Does  the  BFM  department  currently  use  the  Command  Staffing  system 
to  access  or  edit  staffing  data?  What  advantages  or  disadvantages  does 
this  particular  tool  have?  What  data  is  used  from  this  system?  How  is 
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the  data  used?  How  is  this  data  used  for  tracking/managing  personnel 
and/or  projects? 

3.  Constraints 

a.  What  type  of  constraints  should  the  CAT  team  be  aware  of  when 
analyzing  the  current  processes  and  designing  a  system  such  as  CAT? 

4.  After  Paper  Prototype  Development 

a.  What  features/functions  are  missing? 

b.  Are  any  features/functions  in  here  that  are  not  useful  or  are 
unnecessary? 

c.  Are  there  any  features/functions  that  seem  to  be  in  the  wrong  place  or 
are  distracting? 

d.  Are  there  any  changes  needed  to  make  this  prototype  easier  to  use? 

B.  FOR  BRANCH  HEADS  AND  PROJECT  MANAGERS 

Introduction:  We  are  conducting  a  systems  engineering  analysis  on  the  current 
processes  used  by  the  BFM  department  to  obtain  funding  and  project-related  data  for 
AIR-4. OM  leadership  and  project  managers,  as  well  as  the  processes  used  by  project 
managers  to  collect  and  report  project  metrics.  In  particular,  we  are  trying  to  refine  an 
idea  for  a  software  tool  that  provides  project  status  and  funding  information  on  demand. 
The  purpose  of  this  proposed  tool  is  to  assist  leadership  and  project  managers  with 
decisions  they  must  make  regarding  anything  from  individual  projects  to  large-scope 
branch  and/or  division  personnel  planning. 

The  questions  below  are  intended  to  (1)  help  our  team  understand  the  current 
process  you  follow  to  obtain  project-  or  funding-related  information,  and  (2)  help  define 
what  you,  as  users,  consider  most  important  for  the  type  of  system  we  are  proposing. 
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1. 


Data  Collection 


a.  What  administrative  project-related  data  is  collected  on  a  routine 
basis? 

i.  Why  is  this  data  collected  on  a  routine  basis? 

ii.  How  is  this  data  used? 

b.  What  administrative/project  data  does  your  office  or  department 
request  from  BFMs  on  a  routine  basis?  Is  this  information  already 
available  in  the  Longsheets  in  some  way? 

c.  Can  we  have  examples  of  completed  projects  with  the  original  plans, 
schedule,  tracking  data  (EVM  or  other  methodology)?  Could  you 
please  walk  us  through  a  completed  example? 

d.  What  are  some  suggested  improvements  to  the  way  AIR-4.0M 
currently  tracks  and  manages  projects? 

e.  Does  your  office  or  department  use  the  Command  Staffing  system  to 
access  or  edit  staffing  data?  What  advantages  or  disadvantages  does 
this  particular  tool  have?  What  data  is  used  from  this  system?  How  is 
the  data  used?  How  is  this  data  used  for  tracking/managing  personnel 
and/or  projects? 

2.  Data  Reporting 

a.  How  does  project  administrative  data  get  compiled  prior  to  it  being 
sent  to  your  department  for  review?  What  type  of  file  formats?  What 
types  of  charts/graphs  are  used  on  a  routine  basis? 

i.  When  administrative  data  is  received,  does  it  come  in  one 
specific  uniform  format,  or  must  it  be  re-  processed  or 
reformatted  prior  to  sending  it  further  up  the  chain  of  command? 

ii.  How  long  does  the  “re-processing/reformatting”  take  in  a  normal 
week? 
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b.  How  is  project  administrative  data  compiled  and  reported  up  the  chain 
of  command?  What  type  of  file  formats?  What  types  of  charts/graphs 
are  sent  up  the  chain  of  command  on  a  routine  basis? 

c.  On  average,  how  many  projects’  data  are  compiled  and  reported  up  the 
chain  of  command  on  a  weekly  basis? 

d.  What  reporting  tasks  does  your  office  or  department  routinely 
perform? 

i.  How  often  are  reporting  tasks  performed? 

e.  How  often  does  administrative  data  have  to  be  reported?  Or  is  there  a 
standard  time  such  as  the  end/start  of  each  week  the  data  is  provided? 

i.  Are  there  any  examples  of  ad-hoc  data  requests?  How  often  does 
this  happen?  How  long  does  it  take  to  prepare  answers  for  these 
ad-hoc  requests? 

General  Management 

a.  How  does  a  new  request  for  a  project  arrive?  Is  it  in  a  format  of  a 
document  or  a  telephone  call?  What  immediate  steps  must  be  taken  to 
begin  to  “set  up”  the  project? 

i.  Are  there  any  steps  that  are  repetitive  each  time  a  new  project  is 
set  up? 

ii.  Which  of  those  steps  could  be  automated? 

b.  How  are  personnel  assigned  to  new  projects? 

c.  How  is  project  funding  managed  and  tracked? 

i.  Are  the  BFM’s  fund  status  sheets  used  to  manage  and  track 
funding?  How? 

ii.  Does  project  funding  ever  get  broken  down  into  multiple 
accounts  for  management  purposes?  For  example,  does  the  total 


amount  on  a  chargeable  object  get  broken  into  separate  charge 
codes  for  project  aspects  such  as  training,  travel,  materiel,  etc.? 

iii.  Does  your  office  create  unique  artifacts  or  methods  to  track 
status  of  projects? 

1.  What  tools  are  used  to  do  this? 

d.  How  are  project  risks  managed  and  tracked?  How  are  those  risks 
reported? 

e.  Are  there  standard  project  deliverables  that  must  be  produced  for  every 
project?  (ROM,  schedule,  task  statement,  etc.) 

i.  What  tools  are  used  to  create  those  deliverables? 

ii.  Where  and  how  are  those  deliverables  stored?  SharePoint?  Local 
drive? 

f.  What  are  some  high  priority  project  management  areas  that  create 
significant  problems  if  not  managed  properly?  For  example,  if  funds 
get  expended  too  quickly,  or  an  account  is  overcharged,  could  there  be 
trouble?  How  severe  of  a  problem  is  missing  an  important  customer 
milestone?  What  are  the  repercussions  and  how  are  these  problems 
avoided?  Are  any  of  these  management  procedures  that  are  repetitive/ 
tedious  and  could  they  be  automated? 

g.  As  a  project  lead  or  branch  head,  what  are  the  top  three  concerns  with 
regards  to  managing  people,  projects  and  funding? 

h.  One  potential  feature  being  considered  for  the  tool  is  a  “stoplight” 
indicator  for  project  status. 

i.  When  projects  deviate  from  planned  costs,  at  what  percent  or 
amount  deviation  would  your  department  consider  a  project  in  a 
“yellow”  status? 
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ii.  At  what  percent  or  amount  deviation  would  your  department 
consider  a  project  in  a  “red”  status? 

iii.  Similarly,  for  planned  project  schedules,  at  what  percent  or 
amount  of  time  deviation  would  your  department  consider  a 
project  in  a  “yellow”  status?  At  what  percent  or  amount  of  time 
deviation  would  your  department  consider  a  project  in  a  “red” 
status? 

4.  Constraints 

a.  What  type  of  constraints  should  the  CAT  team  be  aware  of  when 
analyzing  the  current  processes  and  designing  a  system  such  as  CAT? 

5.  After  Paper  Prototype  is  Developed 

a.  What  features/functions  are  missing? 

b.  Are  any  features/functions  in  here  that  are  not  useful  or  are 
unnecessary? 

c.  Are  there  any  features/functions  that  seem  to  be  in  the  wrong  place  or 
are  distracting? 

d.  Are  there  any  changes  needed  to  make  this  prototype  easier  to  use? 
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APPENDIX  D.  EXAMPLE  BFM  LONGSHEET 


The  following  figures  provide  a  snapshot  of  the  format  and  type  of  information  contained  in  the  BFM  Longsheets.  The 
Longsheet  content  and  formatting  was  used  as  the  basis  for  developing  the  BFM  dashboard  in  CAT. 
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APPENDIX  E.  USE  CASES 


A.  UC.ALL.l  EXPORT  REPORTS 
User  Story: 

As  the  user,  I  want  to  export  reports  for  all  artifacts  from  the  system. 

Use  Case: 

Description:  CAT  users  request  the  option  to  export  information  for  printing  or 
saving.  The  user  needs  to  be  able  to  choose  which  information  should  be  included  in  the 
exported  file  by  selecting  information,  such  as  funding  graphs,  personnel  lists,  or  funding 
sheets,  from  his  or  her  dashboard  and  select  the  destination  for  the  exported  file. 
Depending  on  the  type  of  report,  the  format  will  either  be  in  Microsoft  Excel  (.xlsx), 
Microsoft  Word  (.docx),  or  Microsoft  PowerPoint  (.pptx)  formats. 

Assumptions:  CAT  contains  the  information  required  for  the  artifact  the  user 

wants. 

Participants:  All  users 

Pre-conditions:  The  user  is  logged  into  the  system. 

Post-conditions:  CAT  provides  the  exported  artifact  to  the  user  in  the  required 

format. 

Flows: 

•  Primary  Flow: 

o  User  requests  to  export  a  CAT  artifact 
o  CAT  provides  options  of  artifacts  that  can  be  exported 
o  User  selects  artifact(s)  to  export 
o  User  selects  format  of  artifacts  to  export 
o  CAT  requests  location  to  download  artifact 
o  User  provides  location 
o  CAT  provides  exported  artifact 
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Use  Case  Diagram 


•  Sequence  Diagram 
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B. 


UC.BFM.l  VIEW  AND  EDIT  FUNDING  STATUS  SHEETS 


User  Story: 

As  the  BFM,  I  want  to  view  and  edit  a  web-based  copy  of  the  funding  status 
sheets  (i.e.,  “Longsheets”). 

Use  Case: 

Description:  The  BFM  users  want  to  be  able  to  view  a  web-version  of  the 
Longsheets.  The  Longsheets,  which  are  traditionally  displayed  in  Microsoft  Excel, 
include  spreadsheets  with  projects’  funding  information,  Section  219  funding,  Section 
852  funding,  expired  funding,  as  well  as  time  card  expenditures.  To  enable  the  system  to 
display  the  Longsheets,  the  system  must  first  in  some  way  ingest  data  from  the  different 
data  sources,  and  then  process  and  reformat  the  data.  The  Longsheets  view  should  also  be 
able  to  accept  and  save  BFM  textual  input  to  the  system. 

Assumptions:  The  funding  status  data  for  the  different  projects  has  been  provided 
to  CAT. 

Participants:  BFM  users 

Pre-conditions:  BFM  is  logged  into  CAT.  The  funding  status  data  for  the 
different  projects  has  been  provided  to  CAT. 

Post-conditions:  BFM  user  has  completed  making  edits  to  Longsheets 

Flows: 

•  Alternative  flow  1 : 

o  BFM  requests  Longsheet  information 
o  CAT  provides  funding  type  selection  option 
o  BFM  requests  projects’  Longsheet  data 
o  CAT  provides  general  project  funding  information 
o  BFM  makes  textual  edits  to  fields  requiring  manual  input 
o  BFM  provides  save  request 
o  CAT  provides  save  functionality 

o  BFM  requests  Section  219  funding  information. 
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o  CAT  provides  Section  219  funding  information 
o  BFM  requests  Section  852  funding  information 
o  CAT  provides  Section  852  funding  information 

•  Alternate  flows  2-n: 

o  BFM  requests  Longsheet  information 
o  CAT  provides  funding  type  selection  option 

■  BFM  may  choose  any  combination  in  which  to  view  the 
different  areas  of  funding  information.  BFM  may  also 
choose  to  edit  and  save  manual  fields  in  any  order. 


•  Use  Case  Diagram 
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Sequence  Diagram 
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C.  UC.PM&BH.l  CREATE  SCHEDULE  ITEMS  AND  ASSIGN 

COMPLETION  DATES 

User  Story: 

•  As  the  PM  or  BH,  I  want  to  be  able  to  create  schedule  items. 

•  As  the  PM  or  BH,  I  want  to  assign  projected  completion  dates  for  all  schedule 
items. 

•  As  the  BH,  I  want  to  be  able  to  accept  or  deny  schedule  items’  completion 
dates  proposed  by  the  PM. 

Use  Case: 

Description:  CAT  will  allow  for  project  manager  and  branch  head  users  to  create 
schedule  items  such  as  milestones  and  deliverables  to  track  project  schedule.  Milestones 
and  deliverables  will  be  treated  the  same  by  the  system;  however,  to  the  users,  a 
deliverable  will  represent  an  artifact  that  is  the  output  a  specific  project.  A  milestone,  on 
the  other  hand,  will  represent  meetings  and  reviews  of  interest. 

For  the  purposes  of  CAT,  schedule  items  are  items  with  specific  dates  and  names. 
They  are  tied  to  a  specific  project  and  are  currently  typically  created  by  a  PM  in  a  project 
plan  that  is  submitted  to  the  BH.  CAT  will  simply  retain  and  present  the  names  and  dates 
associated  with  the  milestone  or  deliverable;  not  the  actual  work  being  conducted  to 
satisfy  a  milestone  or  deliverable.  This  functionality  is  considered  to  be  beyond  the  scope 
of  CAT. 

BH  users  will  provide  specific  milestone  and  deliverable  items  they  expect  a 
project  manager  to  meet  or  complete.  PM  users  will  be  able  to  create  additional  schedule 
items  that  are  agreed  upon  by  the  project  customer.  PM  users  will  also  assign  projected 
completion  dates  to  each  of  the  milestone/deliverable  items  created  by  the  BH,  as  well  as 
those  created  by  the  PM.  The  updated  list  of  milestone/deliverable  items  with  completion 
dates  will  be  submitted  to  the  branch  head  for  approval. 

It  is  anticipated  that  in  most  cases,  the  PM  will  create  the  plan  for  a  project  that 
consists  of  the  schedule  items,  submit  the  plan  (via  CAT)  to  the  BH,  who  then  approves 
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the  milestones,  deliverables,  and  their  associated  dates,  or  possibly  makes  changes  as  he 
sees  fit.  CAT  will  inform  the  PM  of  approval,  changes,  or  rejections  to  the  PM’s  plan. 

Assumptions:  PM  and  BH  users  need  to  create  schedule  items  for  a  project. 
Project  profiles  have  been  created  in  CAT. 

Participants:  PM  and  BH  users 

Pre-conditions:  User  is  logged  in. 

Post-conditions:  Branch  head  has  approved  all  projected  completion  dates 

Flows: 

•  Primary  Flow: 

o  BH  selects  a  specific  project 
o  BH  requests  option  to  enter  schedule  items 
o  CAT  provides  option  to  enter  schedule  items 
o  BH  enters  schedule  items  name 

o  BH  specifies  whether  the  item  is  a  milestone  or  a  deliverable 
o  BH  requests  schedule  item  be  sent  to  PM 
o  CAT  sends  new  schedule  item  to  PM 
o  CAT  alerts  PM  of  a  new  schedule  item 
o  PM  enters  projected  completion  date  for  schedule  item 
o  PM  requests  projected  completion  date  be  sent  to  BH 
o  CAT  sends  projected  completion  date  to  BH 
o  CAT  alerts  BH  of  an  updated  projected  completion  date 
o  BH  approves  projected  completion  date 
o  CAT  alerts  PM  of  approval 

•  Alternate  Flow:  PM  enters  new  schedule  item 

o  PM  requests  option  to  enter  schedule  item 
o  CAT  provides  option  to  enter  schedule  item 
o  PM  enters  schedule  item  name 

o  PM  specifies  whether  the  item  is  a  milestone  or  a  deliverable 
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o 


PM  enters  projected  completion  date 
o  PM  indicates  completion  of  entering  schedule  item 
o  CAT  sends  new  schedule  item  to  BH 
o  CAT  alerts  BH  of  a  new  schedule  item 
o  BH  approves  new  schedule  item 
o  CAT  alerts  PM  of  approval 

•  Alternate  Flow:  BH  rejects  schedule  item 
o  BH  selects  alert 

o  CAT  displays  project  page  with  required  options  to  change,  accept, 
or  reject  project  items  created  by  the  PM 
o  BH  rejects  new  schedule  item  or  a  projected  completion  date 
o  BH  provides  an  explanation 
o  CAT  informs  PM  of  rejected  schedule  item 
o  CAT  provides  PM  the  BH  explanation 


•  Use  Case  Diagram 
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Sequence  Diagram 
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D.  UC.PM&BH.2  RECEIVE  ALERTS  WHEN  ITEMS  ARE  COMING  DUE 
User  Story: 

As  the  PM  or  BH,  I  want  to  receive  alerts  when  schedule  items  are  marked  as 
complete. 

Use  Case: 

Description:  PM  and  BH  users  request  that  CAT  alert  them  when  an  item  is 
coming  due.  The  PM  and  BH  users  will  have  to  specify  how  long  before  an  item  is  due 
that  CAT  should  alert  them.  Users  may  specify  in  their  user  settings  the  default  time 
period  for  this  which  can  be  changed  when  creating  a  new  milestone  or  deliverable.  The 
alert  can  also  be  turned  off. 

Assumptions:  The  milestone  or  deliverable  is  already  in  CAT.  The  users  have 
specified  how  long  before  an  item  is  due  that  he  or  she  should  be  alerted.  CAT  will  know 
what  date  it  is  and  will  be  able  to  calculate  when  the  next  milestone/deliverable  is  coming 
due. 

Participants:  PM  and  BH  users 

Pre-conditions:  User  is  logged  in. 

Post-conditions:  A  due-date  alert  has  been  sent  to  the  PM  and  BH  users 

Flows: 

•  Primary  Flow: 

o  CAT  provides  alert  to  PM  user  that  an  item  is  coming  due 
o  CAT  provides  alert  to  BH  user  that  an  item  is  coming  due 
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Use  Case  Diagram 


•  Sequence  Diagram 
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E. 


UC.PM&BH&SL.l  VIEW  SCHEDULE  ITEMS  TIMELINE 


User  Story: 

As  the  PM,  BH  or  SL,  I  want  to  see  projects’  schedule  items  on  a  timeline. 

Use  Case: 

Description:  PM,  BH,  and  SL  users  request  the  option  to  be  able  to  see  all  project 
schedule  items  in  a  list  and  in  a  timeline  view.  The  list  will  have  the  name  of  the  item, 
whether  the  item  is  a  milestone  or  a  deliverable,  as  well  as  its  projected  completion  date. 
The  timeline  will  display  the  same  information;  however,  it  will  display  the  information 
chronologically  in  a  timeline. 

Assumptions:  The  milestone/deliverable  has  been  entered  into  CAT,  and  has 
been  approved  by  the  BH  user. 

Participants:  PM,  BH,  and  SL  users 

Pre-conditions:  The  milestone/deliverable  has  been  entered  into  CAT,  and  has 
been  approved  by  the  BH  user. 

Post-conditions:  The  user  has  completed  viewing  the  schedule  items 

Flows: 

•  Primary  Flow:  PM  view 

o  PM  requests  a  view  of  schedule  items  for  the  project 
o  CAT  provides  a  tabular  view 
o  CAT  provides  a  timeline  view 
o  PM  specifies  date  range  to  view  schedule  items 
o  CAT  displays  schedule  items  for  the  specific  date  range 

•  Primary  Flow:  BH  view 

o  BH  requests  a  view  of  schedule  items 

o  CAT  provides  a  tabular  view  of  multiple  projects’  schedule  items 
o  CAT  provides  an  aggregated  timeline  view  of  multiple  projects’ 
schedule  items 
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o 


BH  requests  schedule  items  for  a  specific  project 
o  CAT  provides  a  tabular  view 
o  CAT  provides  a  timeline  view 
o  BH  specifies  date  range  to  view  schedule  items 
o  CAT  displays  schedule  items  for  the  specific  date  range 

•  Primary  Flow:  SL  view 

o  SL  requests  a  view  of  schedule  items 

o  CAT  provides  a  tabular  view  of  multiple  projects’  schedule  items 
o  CAT  provides  an  aggregated  timeline  view  of  multiple  projects’ 
schedule  items 

o  SL  requests  milestones/deliverables  for  a  specific  project 
o  CAT  provides  a  tabular  view 
o  CAT  provides  a  timeline  view 
o  SL  specifies  date  range  to  view  schedule  items 
o  CAT  displays  schedule  items  for  the  specific  date  range 


•  Use  Case  Diagram 
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Sequence  Diagram 
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F. 


UC.PM&BH.3  MARK  SCHEDULE  ITEMS  AS  COMPLETE 


User  Story: 

•  As  the  PM,  I  want  to  mark  when  schedule  items  are  completed. 

•  As  the  BH,  I  want  to  receive  alerts  when  schedule  items  are  marked  as 
complete. 

Use  Case: 

Description:  BH  users  request  receiving  alerts  when  a  schedule  items  is  marked 
as  complete. 

Assumptions:  Milestone  or  deliverable  exists  in  CAT 
Participants:  PM  and  BH  users 
Pre-conditions:  User  is  logged  in. 

Post-conditions:  An  alert  has  been  sent  to  the  BH  user 
Flows: 

•  Primary  Flow: 

o  PM  requests  project  schedule  items  list 
o  CAT  provides  schedule  items  list 
o  PM  marks  schedule  items  as  complete 
o  CAT  sends  completion  alert  to  BH 

•  Alternate  Flow:  Due  date  has  occurred 

o  CAT  alerts  PM  if  a  schedule  item’s  due  date  has  occurred 
o  PM  marks  schedule  item  as  complete 
o  CAT  send  completion  alert  to  BH 

•  Alternate  Flow: 

o  CAT  alerts  BH  if  a  schedule  items  due  date  is  past  due 
o  CAT  provides  option  for  BH  to  send  message  to  appropriate  PM 
inquiring  as  to  status  of  schedule  items 
o  BH  selects  option  to  send  PM  status  inquiry 
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o  PM  views  status  inquiry  alert 

o  PM  sets  new  projected  completions  date 

o  CAT  sends  alert  to  BH  with  new  projected  completion  date 


•  Use  Case  Diagram 


•  Sequence  Diagram 


Request  Project 
Milestones  and 
Deliverables  List 

Provide  Schedule  Items 
List 


I 


I  Mark  Schedule  Items  as* 

|  Complete 


|  bend  Completion  AJert  to 

BH 
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G. 


UC.BH&SL.l  VIEW  PERSONNEL  UTILIZATION 


User  Story: 

•  As  the  BH  or  SL,  I  want  to  view  personnel  utilization  for  projects  over  a 
period  of  time. 

Use  Case: 

Description:  To  make  decisions  regarding  hiring  levels,  project  manning,  BH  and 
SL  users  request  insight  into  percentage  utilization  of  personnel  by  project.  BH  users 
request  insight  for  all  projects  that  are  in  the  specific  branch;  whereas  SL  request 
information  for  all  projects.  To  avoid  being  overwhelmed  by  the  number  of  projects,  SL 
requests  a  view  for  aggregated  percentage  utilization  versus  the  ideal  utilization  of 
personnel  by  division  and  by  branch.  The  ideal  utilization  should  be  100%  for  each 
worker  for  each  fiscal  year.  BH  users  also  request  a  percentage  utilization  versus  ideal 
utilization  indicator  for  their  specific  branch.  This  information  allows  for  a  quick 
understanding  of  how  much  effort  is  potentially  available  for  new  projects,  and  if  hiring 
decisions  need  to  be  considered. 

Assumptions:  Personnel  have  been  assigned  to  projects  at  the  branch  level. 

Participants:  PM  and  SL  users 

Pre-conditions:  User  is  logged  in. 

Post-conditions:  User  has  completed  viewing  personnel  utilization.  User  is  aware 
of  whether  the  branch/competency  is  under/overmanned. 

Flows: 

•  Primary  Flow:  BH  views  utilization 

o  BH  requests  personnel  utilization  for  the  branch 
o  BH  provides  a  specific  date  range 
o  CAT  provides  actual  versus  ideal  utilization 
o  CAT  displays  a  list  of  personnel  with  their  percentage  utilization 
and  assigned  projects 
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o 


BH  requests  to  view  a  personnel  assignment  information  for  a 
specific  project 
o  CAT  displays  workers  on  a  specific  project 
o  CAT  displays  percentage  of  workers’  time  assigned  for  project 

•  Alternate  Flow:  SL  views  utilization 

o  SL  requests  utilization  of  personnel  for  the  competency 
o  SL  provides  a  specific  date  range 

o  CAT  provides  actual  versus  ideal  utilization  at  the  competency 
level 

o  SL  requests  utilization  of  personnel  at  the  division  level 
o  CAT  provides  actual  versus  ideal  utilization  at  the  division  level 
o  SL  requests  utilization  of  personnel  at  the  branch  level 
o  CAT  provides  actual  versus  ideal  utilization  at  the  branch  level 
o  SL  requests  utilization  for  a  specific  branch 
o  CAT  provides  actual  versus  ideal  utilization  for  the  branch 
o  CAT  provides  a  list  of  personnel  with  their  percentage  utilization 
and  assigned  projects 


•  Use  Case  Diagram 
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Sequence  Diagram 
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H. 


UC.BH.l  ASSIGN  PERSONNEL  TO  PROJECTS 


User  Story: 

•  As  the  BH,  I  want  to  assign  personnel  to  projects. 

•  As  the  BH,  I  want  to  assign  project  managers  to  projects. 

Use  Case: 

Description:  The  Branch  Head  manages  which  personnel  are  assigned  to  which 
projects.  When  a  new  project  comes  up  or  people  are  added  to  the  competency,  people 

must  be  assigned  to  a  project.  People  may  be  assigned  to  more  than  one  project.  If  so,  a 

certain  amount  of  their  time  will  be  assigned  to  one  project  and  a  certain  amount  of  time 
to  another.  The  BH  is  responsible  for  making  these  decisions.  The  Branch  Head  needs  to 
be  able  to  see  what  people  have  available  time  for  an  upcoming  project  and  for  how  much 
of  that  project  ‘11  have  time  available.  Workers  may  be  over  100%  utilized.  In  this  case, 
CAT  shall  inform  the  BH  of  that  status. 

Assumptions:  Personnel  and  projects  exist  in  CAT 

Participants:  BH  users 

Pre-conditions:  User  is  logged  in. 

Post-conditions:  BH  has  completed  assigning  people  to  projects 

Flows: 

•  Primary  Flow: 

o  BH  requests  list  of  projects 
o  CAT  provides  BH  a  list  of  projects 
o  BH  requests  a  list  of  personnel 
o  CAT  provides  BH  a  list  of  personnel 
o  BH  assigns  a  person  to  a  project 
o  BH  assigns  a  time  period  for  the  person 
o  BH  assigns  percentage  utilization  for  the  person 
o  BH  indicates  that  personnel  assignment  is  complete 
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•  Alternate  Flow:  Person  Over-allocated 

o  BH  requests  list  of  projects 
o  CAT  provides  BH  a  list  of  projects 
o  BH  requests  a  list  of  personnel 
o  CAT  provides  BH  a  list  of  personnel 
o  BH  assigns  a  person  to  a  project 
o  BH  assigns  a  time  period  for  the  person 
o  BH  assigns  percentage  utilization  for  the  person 
o  CAT  indicates  that  the  person  is  over-utilized 
o  BH  indicates  that  assignment  is  complete 

•  Alternate  Flow:  Assign  PM  to  a  project 

o  BH  requests  list  of  projects 
o  CAT  provides  BH  a  list  of  projects 
o  BH  requests  a  list  of  personnel 
o  CAT  provides  BH  a  list  of  personnel 
o  CAT  provides  BH  utilization  for  each  person 
o  BH  assigns  a  person  to  a  project 
o  BH  indicates  that  the  person  is  a  PM 
o  BH  assigns  a  time  period  for  the  person 
o  BH  assigns  percentage  utilization  for  the  person 
o  BH  indicates  that  assignment  is  complete 
o  PM  receives  a  notification  of  being  assigned 

•  Alternate  Flow:  BH  assigns  projects  to  person 

o  BH  requests  list  of  personnel 
o  CAT  provides  BH  a  list  of  personnel 
o  CAT  provides  BH  utilization  for  each  person 
o  BH  requests  a  list  of  projects 
o  CAT  provides  BH  a  list  of  projects 
o  BH  assigns  a  project  to  a  person 
o  BH  assigns  a  time  period  for  the  assignment 
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o  BH  assigns  percentage  utilization  for  the  person 
o  BH  indicates  that  assignment  is  complete 


•  Use  Case  Diagram 


•  Sequence  Diagram 
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I. 


UC.SL.l  VIEW  COMPETENCY  MANNING  LEVELS 


User  Story: 

As  SL,  I  want  to  view  the  competency’s  manning  levels. 

Use  Case: 

Description:  At  the  highest  competency  level,  senior  leadership  requests  to  track 
staffing  allocation.  Staffing  consists  of  the  civilian  personnel  assigned  to  the  competency, 
broken  down  into  NAVAIR  Headquarters  (HQ)  employees  as  well  as  the  workforce  of 
the  two  major  NAVAIR  divisions-  the  Naval  Air  Warfare  Center  Aircraft  Division 
(NAWCAD)  and  Naval  Air  Warfare  Center  Weapons  Division  (NAWCWD).  Each 
component  has  a  target  manning  level,  which  needs  to  be  compared  to  the  actual  current 
employee  population,  and  tracked  over  the  course  of  the  fiscal  year  to  ensure  each 
division  is  properly  manned  over  time.  Current  and  target  civilian  staffing  levels  are 
imported  into  CAT  from  Command  Staffing. 

Assumptions:  A  live  connection  exists  between  CAT  and  Command  Staffing 

Participants:  SL  users 

Pre-conditions:  Personnel  information  has  been  pulled  from  Command  Staffing 
by  CAT  and  assigned  to  division  and  branch  levels.  Division  and  branch  breakdown  has 
been  specified  in  CAT. 

Post-conditions:  SL  has  completed  viewing  manning  levels 

Flows: 

•  Primary  Flow: 

o  SL  requests  the  number  of  people  breakdown  by  NAWCAD  versus 
NAWCWD  versus  NAVAIR  HQ 

o  CAT  provides  a  breakdown  of  people  by  NAWCAD  versus 

NAWCWD  versus  NAVAIR  HQ 

o  CAT  provides  a  target  manning  level 

o  SL  requests  the  number  of  people  by  division 

o  CAT  provides  a  breakdown  of  people  by  division 
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o  SL  requests  the  number  of  people  by  branch 
o  CAT  provides  a  breakdown  of  people  by  branch 

•  Alternate  Flow:  CAT  needs  to  access  Command  Staffing  for  a  list  of 
personnel 

o  SL  requests  the  number  of  people  breakdown  by  NAWCAD  versus 
NAWCWD  versus  NAVAIR  HQ 

o  CAT  requests  Command  Staffing  to  provide  a  list  of  all 
competency  personnel 

o  CAT  provides  a  breakdown  of  people  by  NAWCAD  versus 
NAWCWD  versus  NAVAIR  HQ 
o  CAT  provides  a  target  manning  level 
o  SL  requests  the  number  of  people  by  division 
o  CAT  provides  a  breakdown  of  people  by  division 
o  SL  requests  the  number  of  people  by  branch 


•  Use  Case  Diagram 
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Sequence  Diagram 
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J. 


UC.PM.l  ENTER  STATUS  ITEM  INFORMATION 


User  Story: 

As  the  PM,  I  want  to  provide  project  status  item  information. 

Use  Case: 

Description:  BH  and  SL  users  request  that  PM  users  provide  project  status  item 
information  that  has  the  name  of  the  status  item,  as  well  as  the  urgency.  CAT  is  not 
intended  to  be  a  risk  management  tool;  as  such,  instead  of  associating  project  risks  with 
likelihood  and  consequence  values,  CAT  will  only  require  urgency  information.  The 
urgency  will  subjectively  be  labelled  with  green,  yellow,  or  red  colors.  This  will  quickly 
allow  for  the  different  levels  of  management  to  view  status  item  information  at  a  glance. 
Once  a  status  item  is  specified  by  the  PM,  CAT  will  provide  an  alert  to  the  BH  user 
indicating  a  new  status  item  has  been  entered  into  CAT. 

Assumptions:  PM  users  need  to  enter  project  status  updates  for  their  BHs  to  view 

Participants:  PM  and  BH  Users 

Pre-conditions:  Project  has  been  created  within  CAT 

Post-conditions:  An  alert  has  been  sent  to  the  BH  user 

Flows: 

•  Primary  Flow: 

o  PM  requests  option  to  enter  status  items 
o  CAT  provides  option  to  enter  status  items 
o  PM  provides  status  item  name 
o  PM  provides  status  item  description 
o  PM  provides  status  item  urgency  status 
o  PM  indicates  completion  of  entering  status  items  information 
o  CAT  alerts  BH  of  a  new  status  item 


132 


Use  Case  Diagram 


•  Sequence  Diagram 


Item 
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K. 


UC.PM&BH&SL.3  VIEW  LIST  OF  STATUS  ITEMS 


User  Story: 

As  the  PM  or  BH,  or  SL,  I  want  to  view  projects’  status  items  with  priority  subjectively 
labelled  as  red,  yellow,  or  green. 

Use  Case: 

Description:  BH  and  SL  users  request  the  capability  to  view  all  status  items  that  a 
PM  has  entered  for  a  project.  Project  managers  input  the  status  item  name,  description, 
and  an  urgency  status  to  provide  awareness  to  BH  and  SL  users  on  potential  issues  during 
a  project  execution.  Urgency  status  will  be  demonstrated  by  the  colors  red,  yellow,  green, 
with  red  representing  the  most  urgent  status  item  requiring  attention  and  green 
representing  the  least  urgent  items  requiring  simply  awareness  from  upper  leadership. 

Assumptions:  Status  Items  are  entered  into  CAT 

Participants:  PM,  BH,  and  SL  users 

Pre-conditions:  Status  Items  are  entered  into  CAT 

Post-conditions:  User  has  completed  viewing  Status  Items 

Flows: 

•  Primary  Flow: 

o  PM  requests  a  view  of  project  Status  Items 
o  CAT  provides  a  tabular  view  of  project  Status  Items 
o  PM  specifies  specific  type  of  urgency  to  view 
o  CAT  displays  Status  Items  of  only  a  certain  urgency 

•  Primary  Flow:  BH  view 

o  BH  requests  a  view  of  obstacles  for  branch’s  projects 
o  CAT  provides  a  tabular  view  of  multiple  projects’  obstacles 
o  BH  requests  Status  Items  for  a  specific  project 
o  CAT  provides  a  tabular  view  of  Status  Items  for  a  specific  type 
o  BH  specifies  specific  type  of  urgency  to  view 
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o  CAT  displays  Status  Items  of  only  a  certain  urgency 

•  Primary  Flow:  SL  view 

o  SL  requests  a  view  of  Status  Items 

o  CAT  provides  a  tabular  view  of  multiple  projects’  Status  Items 
o  SL  requests  Status  Items  for  a  specific  project 
o  CAT  provides  a  tabular  view  of  Status  Items  for  a  specific  type 
o  SL  specifies  specific  type  of  urgency  to  view 
o  CAT  displays  Status  Items  of  only  a  certain  urgency 


•  Use  Case  Diagram 
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Sequence  Diagram 
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L. 


UC.PM.2  CREATE  SPEND  PLAN 


User  Story: 

As  the  PM,  I  want  to  be  able  to  create  a  spend  plan  in  the  system. 

Use  Case: 

Description:  To  determine  how  to  execute  funds  for  a  given  project,  PMs  are 
required  to  create  spend  plans.  Spend  plans  are  used  to  track  funding  burndown.  Such 
plans  plan  for  expenditures  by  categories  such  as  personnel  labor,  material,  travel,  or 
training.  These  plans  are  usually  created  for  a  given  fiscal  year  and  provided  to  BHs  for 
approval. 

Assumptions:  PM  users  know  the  types  of  expenditures  they  are  likely  to  incur  in 
a  fiscal  year.  Project  exists  in  CAT. 

Participants:  PM,  BH 

Pre-conditions:  User  is  logged  in. 

Post-conditions:  BH  is  alerted  regarding  a  new  spend  plan 

Flows: 

•  Primary  Flow: 

o  PM  requests  spend  plan  creation  option 
o  CAT  provides  spend  plan  creation  option 
o  PM  specifies  plan  start/end  dates 
o  PM  specifies  expenditure  types 
o  PM  specifies  expenditure  amount 
o  CAT  provides  summation  calculation  of  expenditures 
o  PM  indicates  completion  of  spend  plan 
o  CAT  provides  alert  to  BH 

•  Alternate  Flow:  Spend  plan  rejection 

o  BH  selects  alert  for  new  spend  plan 

o  CAT  provides  options  to  change,  accept,  or  reject  spend  plan 
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o  BH  rejects  spend  plan 
o  BH  provides  an  explanation 
o  CAT  provides  PM  alert  for  spend  plan 
o  PM  selects  alert 

o  CAT  informs  PM  of  rejected  spend  plan 
o  CAT  provides  PM  the  BH  explanation 


•  Use  Case  Diagram 
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Sequence  Diagram 
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M.  UC.PM&BH&SL.4  VIEW  SPEND  PLANS 


User  Story: 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  spend  plans. 

Use  Case: 

Description:  To  determine  how  to  execute  funds  for  a  given  project,  PMs  are 
required  to  create  spend  plans.  Spend  plans  are  used  to  track  funding  burndown.  Such 
plans  plan  for  expenditures  by  categories  such  as  personnel  labor,  material,  travel,  or 
training.  BH  and  SL  users  may  want  to  view  spend  plans  to  verify  that  funding  and 
resources  have  been  appropriately  accounted  for  in  the  planning  of  funding  execution. 

Assumptions:  Spend  plan  has  already  been  created  and  approved 

Participants:  PM,  BH,  SL 

Pre-conditions:  Spend  plan  has  already  been  created  and  approved 

Post-conditions:  User  is  finished  viewing  spend  plan 

Flows: 

•  Primary  Flow:  PM  View 

o  PM  requests  spend  plan 
o  CAT  provides  spend  plan 

•  Primary  Flow:  BH  View 

o  BH  requests  spend  plan  for  specific  project 
o  CAT  provides  spend  plan 

•  Primary  Flow:  SL  View 

o  SL  requests  spend  plan  for  specific  project 
o  CAT  provides  spend  plan 
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Use  Case  Diagram 


•  Sequence  Diagram 
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UC.PM&BH&SL.5  VIEW  FUNDING  EXPIRATION  DATES 


User  Story: 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  funding  expiration  dates. 

Use  Case: 

Description:  Project  funds  have  expiration  dates  that  occur  towards  the  end  of  a 
fiscal  and/or  calendar  year.  PM,  BH,  and  SL  request  that  CAT  provide  information 
regarding  expiring  funds  so  that  resource  allocation  decisions  may  be  made  so  that  by  the 
time  funds  are  expiring  the  PM  has  executed  close  to  100%  of  project  funds.  PM  and  BH 
users  also  request  that  they  receive  alerts  prior  to  funds  expiring.  Each  user  would  specify 
to  the  system  exactly  how  long  before  funds  expiry  the  system  should  provide  an  alert. 

Assumptions:  Chargeable  object  numbers  (CONs)  exist  and  have  been  associated 
with  specific  projects.  Each  CON  provides  a  balance  for  how  much  funding  is  available, 
as  well  as  when  that  funding  is  expiring.  CAT  tracks  the  current  date  and  determines  if 
funds  are  close  to  expiring. 

Participants:  PM,  BH,  SL 

Pre-conditions:  User  is  logged  in. 

Post-conditions:  User  is  finished  viewing  CONs’  expiring  funds 

Flows: 

•  Primary  Flow:  PM  View 

o  PM  requests  CON  details 
o  CAT  provides  CON  name 
o  CAT  provides  CON  number 
o  CAT  provides  CON  balance 
o  CAT  provides  CON  expiration  date 

•  Primary  Flow:  BH  View 

o  BH  requests  list  of  CONs  associated  with  projects 
o  CAT  provides  CONs  associated  with  projects 
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o 


BH  requests  CON  details  for  specific  project 
o  CAT  provides  CON  name 
o  CAT  provides  CON  number 
o  CAT  provides  CON  balance 
o  CAT  provides  CON  expiration  date 

•  Primary  Flow:  SL  View 

o  SL  requests  list  of  CONs  associated  with  projects 
o  CAT  provides  CONs  associated  with  projects 
o  SL  requests  CON  details  for  specific  project 
o  CAT  provides  CON  name 
o  CAT  provides  CON  number 
o  CAT  provides  CON  balance 
o  CAT  provides  CON  expiration  date 

•  Alternate  Flow:  Expiration  Alert 

o  CAT  provides  alert  to  PM  about  expiring  funds 
o  CAT  provides  alert  to  BH  about  expiring  funds 


•  Use  Case  Diagram 
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Sequence  Diagram 
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O.  UC.PM&BH&SL.6  VIEW  PLANNED  VERSUS  ACTUAL 
EXPENDITURES 

User  Story: 

As  the  PM,  BH  or  SL,  I  want  to  view  projects’  planned  versus  actual 
expenditures.  I  want  to  know,  based  off  my  current  expenditure  rate  if  I  will  over  or 
under  expend. 

Use  Case: 

Description:  To  execute  project  funds  as  close  to  100%  as  possible,  PMs  require 
an  understanding  of  how  their  actual  expenditures  compare  to  their  planned  expenditures. 
BH  and  SL  users  also  want  to  see  aggregated  planned  versus  actual  expenditures  at  the 
division  and  branch  levels,  in  addition  to  viewing  planned  versus  actual  expenditures  at 
the  project  level.  CAT  should  be  able  to  indicate  when  funding  will  be  fully  expended, 
based  on  spending  habits.  Furthermore,  CAT  should  also  be  able  to  calculate  how  far 
above  or  below  the  planned  expenditure  rate  a  project  is  and  alert  the  user  if  it  meets  a 
user  specified  criteria. 

Assumptions:  Chargeable  object  numbers  (CONs)  exist  and  have  been  associated 
with  specific  projects.  CAT  has  a  live  connection  to  external  databases,  such  as  NERP,  to 
obtain  updated  expenditure  information  on  CONs.  A  spend  plan  has  already  been  created 
in  the  system. 

Participants:  PM,  BH,  SL 

Pre-conditions:  User  is  logged  in 

Post-conditions:  User  is  finished  viewing  planned  versus  actual  expenditures 

Flows: 

•  Primary  Flow:  PM  View 

o  PM  requests  planned  versus  actual  expenditures  for  a  specific 
project 

o  CAT  displays  planned  versus  actual  expenditures 
o  CAT  displays  forecasted  projected  funding  completion  date 
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o  CAT  displays  over/under-expenditure  bounds 

•  Primary  Flow:  BH  View 

o  BH  requests  aggregated  planned  versus  actual  expenditures  at  the 
branch  level 

o  CAT  displays  aggregated  planned  versus  actual  expenditures  at  the 
branch  level 

o  BH  requests  planned  versus  actual  expenditures  for  a  specific 
project 

o  CAT  displays  planned  versus  actual  expenditures 
o  CAT  displays  forecasted  projected  funding  completion  date 
o  CAT  displays  over/under-expenditure  bounds 

•  Primary  Flow:  SL  View 

o  BH  requests  aggregated  planned  versus  actual  expenditures  for  a 
specific  division 

o  CAT  displays  aggregated  planned  versus  actual  expenditures  at  the 
division  level 

o  BH  requests  aggregated  planned  versus  actual  expenditures  for  a 
specific  branch 

o  CAT  displays  aggregated  planned  versus  actual  expenditures  at  the 
branch  level 

o  SL  requests  planned  versus  actual  expenditures  for  a  specific 
project 

o  CAT  displays  forecasted  projected  funding  completion  date 
o  CAT  displays  over/under-expenditure  bounds 
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Use  Case  Diagram 


•  Sequence  Diagram 


Over/underexpenditure 
Bounds 
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P.  UC.PM&BH&SL.2  VIEW  PROJECTS  UNDER  PURVIEW 
User  Story: 

As  the  PM,  BH,  or  SL,  I  want  to  see  all  projects  for  which  I  have  permission. 

Use  Case: 

Description:  In  order  for  users  to  obtain  the  information  that  they  need  to  make 
management  decisions,  they  need  to  be  able  to  view  all  the  projects’  profiles  that  they 
have  permission  to  view.  Furthermore,  the  system  must  be  able  to  ensure  that  any  users 
that  do  not  need  to  view  other  users’  projects  are  not  able  to  view  those  projects. 

Assumptions:  Project  profile  exists,  and  a  schema  has  been  set  up  to  determine 
who  has  access  to  view  specific  projects’  profiles  and  data. 

Participants:  PM,  BH,  SL 

Pre-conditions:  User  is  logged  in 

Post-conditions:  User  is  finished  viewing  project 

Flows: 

•  Primary  Flow:  PM 

o  PM  requests  list  of  projects  under  purview 
o  CAT  provides  list  of  accessible  projects 
o  PM  navigates  to  accessible  project 

•  Primary  Flow:  BH 

o  BH  requests  list  of  projects  under  purview 
o  CAT  provides  list  of  accessible  projects 
o  BH  navigates  to  accessible  project 

•  Primary  Flow:  SL 

o  SL  requests  list  of  projects  under  purview 
o  CAT  provides  list  of  accessible  projects 
o  SL  navigates  to  accessible  project 
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Use  Case  Diagram 


•  Sequence  Diagram 
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APPENDIX  F.  TRACEABILITY  BETWEEN  USER  STORIES  AND 

USE  CASES 


User  Story 

Number 

User  Story  Name 

Use  Case 

Number 

Use  Case  Name 

US.F.l 

View  Funding 

Expiration  Information 

UC.PM&BH&SL.5 

View  Funding  Expiration 
Dates 

US.F.2 

View  Spend  plans 

UC.PM&BH&SL.4 

View  Spend  plans 

US.F.3 

View  Planned  versus 
Actual  Expenditures 

UC.PM&BH&SL.6 

View  Planned  Versus 

Actual  Expenditures 

US.F.4 

Create  Spend  plan 

UC.PM.2 

Create  Spend  plan 

US.F.5 

View  and  Edit  All 
Funding  Status  Sheets 

UC.BFM.l 

View  and  Edit  Funding 
Status  Sheets 

US.G.l 

Export  Reports 

UC.ALL.l 

Export  Reports 

US.G.2 

View  All  Projects 

Under  Purview 

UC.PM&BH&SL.2 

View  Projects  Under 
Purview 

US.SI.l 

View  List  of  Status 

Items 

UC.PM&BH&SL.3 

View  List  of  Status  Items 

US.SI.2 

Enter  Status  Item 
Information 

UC.PM.l 

Enter  Status  Item 
Information 

US.P.l 

Assign  personnel  to 
projects 

UC.BH.l 

Assign  Personnel  to 

Projects 

US. P.2 

Assign  Project  Manager 
to  a  project 

UC.BH.l 

Assign  Personnel  to 

Projects 

US. P.3 

View  Personnel 
Utilization 

UC.BH&SL.l 

View  Personnel  Utilization 

US. P.4 

View  Competency 
Manning  Levels 

UC.SL.l 

View  Competency 

Manning  Levels 

US.S.l 

Create  Schedule  Items 

UC.PM&BH.  1 

Create  Schedule  Items  and 
Assign  Completion  Dates 

US.S.2 

Accept/Deny  Proposed 
Completion  Dates 

UC.PM&BH.  1 

Create  Schedule  Items  and 
Assign  Completion  Dates 

US.S.3 

Assign  Projected 
Completion  Dates 

UC.PM&BH.  1 

Create  Schedule  Items  and 
Assign  Completion  Dates 

US.S.4 

View  Schedule  Items 

List 

UC.PM&BH&SL 

Project  Schedule  Items  in  a 
List  or  on  a  Timeline 
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User  Story 

Number 

User  Story  Name 

Use  Case 

Number 

Use  Case  Name 

US.S.5 

Receive  Alert  for 
Completed  Schedule 
Items 

UC.PM&BH.3 

Mark  Schedule  as 

Complete 

US.S.6 

Mark  when  items  arc 
completed 

UC.PM&BH.3 

Mark  Schedule  as 

Complete 

US.S.7 

Receive  Alert  when 
items  are  coming  due 

UC.PM&BH.2 

Receive  Alerts  When 

Items  are  Coming  Due 

US.S.8 

View  Schedule  Items 
Timeline 

UC.PM&BH&SL 

Project  Schedule  Items  in  a 
List  or  on  a  Timeline 
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APPENDIX  G.  CAT  AFFINITY  DIAGRAMS 
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Figure  G-l.  Initial  “RealtimeBoard”  Affinity  Diagram  for  the  CAT  system 
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Figure  G-2.  Initial  Affinity  Diagram  of  Requirements  Data:  Project  Profiles 
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Figure  G-3.  Initial  Affinity  Diagram  of  Requirements  Data:  Users/ Administration 
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Figure  G-4.  Initial  Affinity  Diagram  of  Requirements  Data:  User  Dashboards 
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Figure  G-5.  Initial  Affinity  Diagram  of  Requirements  Data:  Project  Dates  Management 
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Figure  G-6.  Initial  Affinity  Diagram  of  Requirements  Data:  Funding 
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APPENDIX  H.  CAT  REQUIREMENTS  TRACEABILITY  MATRIX 


Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R. 

CAT  Requirements 

F. 

Perform  CAT  Functions 

R.  1 

User  Profile 
Requirements 

UC.ALL.l 

Export  Reports 

UC.PM&BH&SL.2 

View  Projects  Under  Purview 

R.  1.1 

User  Profile  Inputs 

R.  1.1.1 

Save  user  data 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  request  to  save  data. 

F.2.2.4 

Accept  Senior  Leadership  Input  From  GUI 

F.2.2.7 

Accept  BH  Input  from  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

F.4 

Perform  Data  Storage  Operations 

F.4.2 

Store  Data 

F.4.3 

Accept  Requests  for  Data 

F.4.5 

Retrieve  Data 

R.  1.1.2 

User  login 
credentials 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  user  login 
credentials. 

F.l 

Perform  Sign  on  Functions 

F.1.1 

Provide  Access  Interface 

F.l. 2 

Request  CAC  Credentials 

R.l.1.3 

Create  new  project 
for  user 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  creating  a  new 
project  for  the  user. 

F.2.2.5.3.2.4 

Provide  Interface  to  Create  New  Project 

F.2. 2.5. 3.2.4. 1 

Display  New  Project  Interface 

F.2.2.5.3.2.4. 1.1 

Allow  for  Project  Name  to  be  Specified 

F.2.2.5.3.2.4. 1.4 

Allow  a  Project  Manager  to  be  Specified 

F.2.2.5.3.2.4. 1.5 

Does  Project  Have  a  Name? 

F.2.2.5.3.2.4. 1.6 

Inform  User  Project  Cannot  be  Created 
without  a  Name 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.2.5.3.2.4.2 

Save  New  Project  Data 

R.l.1.3.1 

Assign  project 
description 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  associating  a 
project  description  to  a 
project. 

F.2. 2.5. 3.2.4. 1.3 

Allow  for  a  Project  Description  to  be 

Specified 

R.l.1.3.2 

Assign  start/end 
date  to  a  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  associating  a 
start/end  date  to  a  project. 

F.2. 2.5. 3.2.4. 1.2 

Allow  for  Project  Date  Range  to  be  Specified 

R.  1.1.4 

Edit  user  requested 
outputs 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  to  edit 
user  requested  data 
outputs.  [u][/u] 

F.2.2.4 

Accept  Senior  Leadership  Input  From  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

R.l.1.4.1 

Edit  user  displayed 
graphs 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  editing  user 
displayed  graphs. 

F.2.2.4 

Accept  Senior  Leadership  Input  From  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

R.  1.1. 4.2 

Edit  user  displayed 
Longsheets 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  editing  user 
displayed  Longsheets. 

F.2.2.4 

Accept  Senior  Leadership  Input  From  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

R.  1.1. 4.3 

Edit  user  displayed 
timelines 

The  CAT  system  shall  be 
capable  of  accepting  the 

F.2.2.4 

Accept  Senior  Leadership  Input  From  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

input  of  editing  user 
displayed  timelines. 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

R.  1.1. 4.4 

Edit  user  displayed 
lists 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  editing  user 
displayed  lists. 

F.2.2.4 

Accept  Senior  Feadership  Input  From  GUI 

F.2.2.10 

Accept  Project  Manager  Input  from  GUI 

F.2.2.13 

Accept  Administrator  Input  from  GUI 

F.2.2.16 

Accept  BFM  Input  from  GUI 

F.2.4.5 

Accept  User  Input  from  GUI  Module 

R.  1.1.5 

Terminate  User 
Session 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  to  terminate  a  user 
session. 

F.3 

Perform  Session  Termination  Procedures 

F.3.1 

Accept  Session  Timeout  Exit 

F.3. 4 

Determine  if  Exit  Was  User  Initiated 

F.3. 7 

Terminate  Session 

R.l.1.6 

Create  User 

Message 

The  CAT  Systems  shall 
be  capable  of  accepting 
the  input  of  user  entered 
message  data  to  be  sent  to 
another  user. 

F.2.2.5.7.2 

Display  Option  to  Send  another  User  a 
Message 

F.2.3.4.5 

Provide  Message  Transfer  Service 

R.l.1.6.1 

Associate  Message 
to  Project 

The  CAT  System  shall  be 
capable  of  accepting  the 
input  of  associating  a  user 
message  to  a  project. 

F.2.3.4.5 

Provide  Message  Transfer  Service 

R.  1.1.7 

Create  New  User 
Profile 

When  the  CAT  system 
displays  the  log  on 
interface,  it  shall  be 
capable  of  accepting  the 
input  to  create  a  new  user 
profile. 

F.2.1.3 

Create  New  User  Profile 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.  1.2 

User  Profile 

Functional 

Requirements 

R.  1.2.1 

Verify  user 
credentials 

The  CAT  system  shall  be 
capable  of  verifying  user 
credentials. 

F.l 

Perform  Sign  on  Functions 

F.1.2 

Request  CAC  Credentials 

F.l. 3 

Transmit  User  Credentials  to  BIG  IP 

F.2.1.2 

Determine  User  Type 

F.2.3.1. 1.2.1 

Determine  Division  User  is  Responsible  For 

R.  1.2.2 

Grant  user  access 

The  CAT  system  shall  be 
capable  of  granting  user 
access. 

F.l 

Perform  Sign  on  Functions 

F.l. 4 

Grant  Access 

F.2.1.2 

Determine  User  Type 

F.2.3.1. 1.2.1 

Determine  Division  User  is  Responsible  For 

R.l.2.3 

Store  data 

The  CAT  system  shall  be 
capable  of  storing  data. 

F.2.1.3 

Create  New  User  Profile 

F.2.4.1 

Create  New  User  Profile 

F.3.6 

Save  User  Data 

F.4.1 

Accept  Data  Storage  Requests 

F.4.2 

Store  Data 

F.4.3 

Accept  Requests  for  Data 

F.4.4 

Send  Data 

F.4.5 

Retrieve  Data 

R.l.2.3.1 

Save  user  inputs 

The  CAT  system  shall  be 
capable  of  saving  user 
inputs. 

F.3.6 

Save  User  Data 

F.4 

Perform  Data  Storage  Operations 

F.4.2 

Store  Data 

R.l.2.3.2 

Save  data  elements 
from  external 

sources 

The  CAT  system  shall  be 
capable  of  saving  data 
elements  from  external 

sources. 

F.4.5. 1 

Retrieve  and  Save  Data  From  ERP  Every 
Week 

R.l.2.3. 3 

Save  user  profile 

The  CAT  system  shall  be 

F.2.1.4 

Request  User  Settings 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

settings 

capable  of  saving, 
changing  and  updating  a 
user’s  profile  settings. 

F.2.1.5 

Provide  Local  User  Settings 

F.2.2.5. 3.2.7. 1 

Retrieve  User  Data  from  Profile  Manager 
Module 

F.2.2.1 1.1 

Apply  User  Specific  Settings  to  Admin 
Dashboard 

F.2.4.2 

Change  Existing  User  Profile 

F.2.4.3.1.2 

Edit  User  Type 

F.2.4.3.2 

Edit  User  Specified  Settings 

F.2.4.3.2.2 

Manage  Default  User  Settings 

F.2.4.4 

Save  User  Profile 

R.l.2.3.3.1 

Save  Senior 
Leadership’s  profile 
settings 

The  CAT  system  shall  be 
capable  of  saving  the 
Senior  Leadership's 
profile  settings. 

F.2.4.4 

Save  User  Profile 

R.l.2.3.3 

Save  user  profile  settings 

R.l.2.3.3.2 

Save  Branch  Head’s 
profile  settings 

The  CAT  system  shall  be 
capable  of  saving  the 
Branch  Head’ s  profile 
settings. 

F.2.4.4 

Save  User  Profile 

R.l.2.3.3.3 

Save  Project 
Manager’s  profile 
settings 

The  CAT  system  shall  be 
capable  of  saving  the 
Project  Manager’s  profile 
settings. 

F.2.4.4 

Save  User  Profile 

R.l.2.3.3.4 

Save  Budget 
Financial 

Manager’s  profile 
settings 

The  CAT  system  shall  be 
capable  of  saving  the 
Budget  Financial 
Manager’s  profile 
settings. 

F.2.4.4 

Save  User  Profile 

R.l.2.3.3.5 

Save  CAT 
Administrator’ s 

The  CAT  system  shall  be 
capable  of  saving  the 

F.2.2.1 1.1 

Apply  User  Specific  Settings  to  Admin 
Dashboard 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

profile 

CAT  Administrator's 
profile  settings. 

F.2.4.4 

Save  User  Profile 

R.  1.2.4 

Customize 

privilege/restriction 

settings 

The  CAT  system  shall  be 
capable  of  customizing 
data  field  privilege/ 
restriction  settings  for 
each  profile. 

F.2.1.1 

Determine  User  Status 

F.2.2.1 

Determine  User  Type 

F.2.2.14.1 

Apply  User  Specific  Settings  to  BFM 
Dashboard 

F.2.3. 1.1.1 

Determine  Level  of  Aggregation 

F.2.4.3.2.1 

Manage  User  Settings  for  a  Specific  Project 

R.  1.2.5 

Detect  user  errors 

The  CAT  system  shall  be 
capable  of  detecting  user 
errors. 

F.2. 2.5. 3.2.4. 1.6 

Inform  User  Project  Cannot  be  Created 
without  a  Name 

F.2.2.6 

Validate  Input  from  BH 

R.  1.2.6 

Logoff  user 

When  requested  by  the 
user  to  terminate  the 
session,  the  CAT  system 
shall  logoff  the  user. 

F.3.1 

Accept  Session  Timeout  Exit 

F.3.2 

Accept  User  Initiated  Exit 

F.3.4 

Determine  if  Exit  Was  User  Initiated 

F.3.7 

Terminate  Session 

R.  1.2.7 

Send  Messages 
from  one  user  to 
another 

The  CAT  System  shall  be 
capable  of  sending  user 
message  to  an  existing 
user’s  profile. 

F.2.2.5.7.2 

Display  Option  to  Send  another  User  a 
Message 

F.2.3.4.5 

Provide  Message  Transfer  Service 

R.l.2.8 

Data  Validation 

The  CAT  System  shall  be 
capable  of  validating  user 
input  to  ensure  it  is  in  an 
acceptable  format. 

F.2.2.3 

Validate  Input  from  SL 

F.2.2.6 

Validate  Input  from  BH 

F.2.2.9 

Validate  Input  from  PM 

F.2.2.12 

Validate  Input  from  Administrator 

F.2.2.15 

Validate  Input  from  BFM 

R.1.3 

User  Profile 

Outputs 

R.l.3.1 

Provide  Graphical 
User  Interface 

The  CAT  system  shall  be 
capable  of  providing  a 
user  graphical  interface  to 

F.2 

Perform  Competency  Administration 

F.2.1.2 

Determine  User  Type 

F.2. 2 

Provide  Graphical  User  Interface 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

the  user. 

F.2.3.3.3.2 

Send  Data  to  GUI  for  Display 

R.l.3.1.1 

Display  Senior 

The  CAT  system  shall  be 

F.2.2.2 

Display  Senior  Leadership  GUI 

Leadership’s 

dashboard 

capable  of  displaying  the 
Senior  Leadership’s 
dashboard. 

F.2.2.2.5 

Display  Manning  View 

F.2.3. 1.1.2 

Generate  Staffing  Level  View  Data 

F.2.3.1. 1.2.1 

Determine  Division  User  is  Responsible  For 

F.2.3.1. 1.2.2 

Determine  Staffing  Target  Level 

F.2.3.1. 1.2.3 

Determine  Branches  in  Division 

F.2.3.1. 1.2.5 

Determine  Historical  Staffing  Levels 

F.2.3.1. 1.2.6 

Determine  Current  Staffing  Levels 

F.2.3.1. 1.2.7 

Compile  Staffing  Level  Data 

F.2.3.1. 1.2.8 

Send  Staffing  Level  Data  to  GUI  Module 

F.2.3. 3. 8 

Is  user  Senior  Leadership? 

F.2.3. 3.9 

Aggregate  Funding  Curves  on  a  Competency 
Level 

F.4.5.2 

Retrieve  Data  from  CAT  Storage 

R.l.3.1.2 

Display  Branch 

The  CAT  system  shall  be 

F.2.2.5 

Display  BH  GUI 

Head’s  dashboard 

capable  of  displaying  the 
Branch  Head’ s 
dashboard. 

F.2.2.5.3 

Display  BH  People  to  Projects  Dashboard 

GUI 

F.2.2.5. 3. 2 

Provide  BH  People  to  Project  Display 
Ancillaries 

F.2.2.5.5 

Display  BH  Funding  Graph 

F.2. 2.5.5. 1 

Accept  Branch  Head  Request  for  Funding 
Rollup  or  Projects  Specific  Funding  Graph 

F.2.2.5.5. 2 

Display  Branch  Rollup  Funding  Graph 

F.2.2.7 

Accept  BH  Input  from  GUI 

F.2.3.1. 1.4 

Generate  Branch  Head  People  to  Projects 
Dashboard  View  Data 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.3. 1.1.5 

Send  Branch  Head  People  to  Projects 
Dashboard  View  Data  to  GUI  Module 

F.2.3.3.6 

Is  user  a  Branch  Head? 

F.2.3. 3.7 

Aggregate  Funding  Curves  on  a  Branch 

Level 

F.4.5.2 

Retrieve  Data  from  CAT  Storage 

R.l.3.1.3 

Display  Project 

Manager’s 

dashboard 

The  CAT  system  shall  be 
capable  of  displaying  the 
Project  Manager’s 
dashboard. 

F.2.2.8 

Display  Project  Manager  GUI 

F.2.2.8.2.5 

Display  Funded  Amount 

F.2.2.8. 3 

Display  PM  Funding  Status  Table 

F.2.2.8. 3. 5 

Display  Labor  Estimate 

F.2.2.8.5 

Display  PM  Project  Deliverable  Table 

F.4.5.2 

Retrieve  Data  from  CAT  Storage 

R.l.3.1.4 

Display  Budget 
Financial 

Manager’s 

dashboard 

The  CAT  system  shall  be 
capable  of  displaying  the 
Budget  Financial 
Manager’s  dashboard. 

F.2.2.14 

Display  BFM  GUI 

F.2.2.14.1 

Apply  User  Specific  Settings  to  BFM 
Dashboard 

F.2.2.14.2 

Retrieve  Data  for  BFM  Dashboard 

F.2.2.14.3 

Display  BFM  Dashboard 

F.2.3. 3. 11 

Associate  BFM  Notes  to  Project  Data 

R.l.3.1.5 

Display  CAT 
Administrator’ s 
dashboard 

The  CAT  system  shall  be 
capable  of  displaying  the 
CAT  Administrator's 
dashboard. 

F.2.2.1 1 

Display  Administrator  GUI 

F.2.2.11.1 

Apply  User  Specific  Settings  to  Admin 
Dashboard 

F.4.5.2 

Retrieve  Data  from  CAT  Storage 

R.l.3.2 

Display  user  profile 
information 

The  CAT  system  shall  be 
capable  of  displaying  user 
profile  information. 

F.2.1 

Retrieve  User  Specific  Settings 

F.2.1.3 

Create  New  User  Profile 

F.2.4.1 

Create  New  User  Profile 

R.l.3.2.1 

Apply  User  Settings 

The  CAT  system  shall  be 

F.2.1.4 

Request  User  Settings 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

to  Dashboard 

capable  of  displaying 
the  dashboard  with 
the  user  customized 
settings  applied 

F.2.2.5. 3.2.7. 1 

Retrieve  User  Data  from  Profile  Manager 
Module 

R.l.3.3 

Display  selected 
projects  for  user 

The  CAT  system  shall  be 
capable  of  displaying 
selected  projects  for  the 
user. 

F.2.2.2.1 

Apply  User  Specific  Settings  to  SL 

Dashboard 

F.2.2.5.2 

Apply  User  Specific  Settings  to  BH 

Dashboard 

F.2.2.8.1 

Apply  User  Specific  Settings  to  PM 

Dashboard 

F.2.2.8.7.1 

Display  Option  to  Select  a  Specific  Project  to 
Display 

F.2.3 

Provide  Project  Monitoring  Functions 

R.l.3.4 

Display  user  project 
alerts 

The  CAT  system  shall  be 
capable  of  displaying  user 
project  alerts. 

F.2.2.5.3.2.4.3 

Trigger  Alert  to  Assigned  Project  Manager  of 
New  Project  Assignment 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R.l.3.4.1 

Display  “new 
project  created” 
alert 

When  a  new  project  is 
created,  the  CAT  system 
shall  provide  an  alert  to 
specified  user  profiles. 

F.2.2.5.3.2.4.3 

Trigger  Alert  to  Assigned  Project  Manager  of 
New  Project  Assignment 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R. 1.3. 4.2 

Display  Prompt  to 
Save  Unsaved  Data 

When  a  user  session  is 
terminated,  the 

CAT  System  shall  be 
capable  of  displaying  a 
prompt  to  ensure  unsaved 
data  is  not  inadvertently 
lost. 

F.3.3 

Determine  if  Most  Recent  Data  Saved 

F.3.5 

Send  Save  Prompt 

F.3.6 

Save  User  Data 

F.3.7 

Terminate  Session 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.l.3.5 

Export  project  data 

The  CAT  system  shall  be 
capable  of  exporting  user 
project  data. 

F.2.5 

Provide  Export  Functionality 

R.l.3.5.1 

Export  in  MS  Excel 
format 

The  CAT  system  shall  be 
capable  of  exporting  user 
project  data  in  the 
Microsoft  Excel  format. 

F.2.5.3 

Excel  Data  File 

R.l.3.5. 1.1 

Export  Raw  Data 

The  CAT  system  shall  be 
capable  of  exporting  raw 
data  to  Excel  for  user 
manipulation 

F.2.3.3.3.3 

Make  Data  Available  for  Export  to  Excel 

R.l.3.5.2 

Export  in  MS 
PowerPoint  format 

The  CAT  system  shall  be 
capable  of  exporting  user 
project  data  in  the 
Microsoft  PowerPoint 
format. 

F.2.5.2 

Export  Data  into  PowerPoint 

R.l.3.5. 3 

Export  in  CAT  File 
Format 

The  CAT  system  shall  be 
capable  of  exporting  user 
project  data  in  the  CAT 
file  format. 

F.2.5.4 

Export  Data  in  a  CAT  File  Format 

R.l.3.5.4 

Export  data  to  a 
network  printer 

The  CAT  system  shall  be 
capable  of  exporting  user 
project  data  to  a  network 
printer. 

F.2.5. 1 

Export  Data  for  Printing 

R.l.3.6 

Display  a  Message 
Received  from 
Another  User 

The  CAT  System  shall  be 
capable  of  displaying  a 
message  received  from 
another  user. 

F.2.2.5.7.2 

Display  Option  to  Send  another  User  a 
Message 

F.2.3.4.5 

Provide  Message  Transfer  Service 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.l.3.6.1 

Display  Message 
Association 

The  CAT  System  shall  be 
capable  of  displaying  the 
project  name/number 
associated  with  a 
message. 

F.2.3.4.5 

Provide  Message  Transfer  Service 

R.2 

Project  Schedule 

Item  Requirements 

UC.PM&BH&SL.  1 

Project  Schedule  Item  in  a  List  or  on  a 
Timeline 

UC.PM&BH.l 

Create  Schedule  Items  and  Assign 

Completion  Dates 

UC.PM&BH.2 

Receive  Alerts  When  Items  are  Coming  Due 

UC.PM&BH.3 

Mark  Schedule  Items  as  Complete 

R.2.1 

Schedule  Item 

Inputs 

R.2. 1.1 

Link  schedule  items 
to  a  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  linking  a 
schedule  items  to  a 
project. 

F.2.3.2.1 

Accept  Schedule  Item  Data 

R.2.1. 2 

Assign  a  name  to 
schedule  items 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a  name 
to  schedule  items. 

F.2.3.2.1.1 

Accept  Schedule  Item  Name 

R.2.1. 3 

Assign  a  description 
to  schedule  items 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
description  to  schedule 
items. 

F.2.3.2.1. 5 

Accept  Schedule  Item  Description 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.2.1.4 

Assign  a  date  to 
schedule  items 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a  date 
to  schedule  items. 

F.2.3.2.1.3 

Accept  Schedule  Item  Date 

R.2.1.5 

Assign  project 
duration 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
project  duration. 

F.2. 2.5. 3.2.4. 1.2 

Allow  for  Project  Date  Range  to  be  Specified 

R.2.1.6 

Assign  a  note  to 
schedule  items 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a  note 
to  schedule  items. 

F.2.3.2.1.4 

Accept  Schedule  Item  Note 

R.2.1.7 

Assign  a  schedule 
item  as  complete 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
schedule  item  as 
complete. 

F.2.3.2 

Provide  Schedule  Item  Tracking  Functions 

R.2.1.8 

Accept/Reject  a 
proposed  schedule 
item  date 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  accepting/ 
rejecting  a  proposed 
schedule  item  date. 

F.2.2.5.5.5 

Send  Schedule  Item  Inputs  to  Approval 
Authority 

F.2.3.2. 3 

Retrieve  Schedule  Item  Approval  Status 

R.2.1.9 

Filter  schedule  item 
data 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  filtering  schedule 
item  data. 

F.2.2.2.4.3 

Display  DH  Schedule  Item  Filter  Options 

F.2.2.5.6.3 

Display  BH  Schedule  Item  Filter  Options 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.2.1.10 

Assign  a  schedule 
item  as  either  a 
milestone  or 
deliverable 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
schedule  item  as  a 
milestone  or  deliverable. 

F.2.3.2.1.2 

Accept  Schedule  Item  Type 

R.2.2 

Schedule  Item 

Functional 

Requirements 

R.2.2.1 

Organize  schedule 
item  data 

The  CAT  system  shall  be 
capable  of  organizing 
schedule  item  data. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

R.2.2. 1.1 

Sort  schedule  item 
data 

chronologically 

The  CAT  system  shall  be 
capable  of  sorting 
schedule  item  data 
chronologically. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

R.2.2. 1.2 

Sort  schedule  item 
data  alphabetically 

The  CAT  system  shall  be 
capable  of  sorting 
schedule  item  data 
alphabetically. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

R.2.2. 1.3 

Sort  schedule  item 
data  by  project 
duration 

The  CAT  system  shall  be 
capable  of  sorting 
schedule  item  data  by 
project  duration. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

F.2.2.5.3.2.3. 5 

Sort  by  Date  Range 

R.2.2. 1.4 

Sort  schedule  item 
data  by  type 

The  CAT  system  shall  be 
capable  of  sorting 
schedule  item  data  by 
type. 

F.2.2.5.3.2.3 

Provide  Sort  Function 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.2.2.2 

Calculate  time  until 
the  date  of  a 
schedule  item 

The  CAT  system  shall  be 
capable  of  calculating  the 
time  until  the  date  of  a 
schedule  item. 

F.2.3.2.4 

Calculate  Schedule  Item  Information  for 
Display 

R.2.3 

Schedule  Item 
Outputs 

R.2.3.1 

Display  schedule 
item  timeline 

The  CAT  system  shall  be 
capable  of  displaying  a 
schedule  item  timeline. 

F.2. 2.2.4. 1 

Display  Division  Schedule  Item  Timeline 

F.2.2.5.6.1 

Display  Branch  Schedule  Item  Timeline 

F.2.2.8.5 

Display  PM  Project  Deliverable  Table 

F.2.3.2.1.7 

Compile  Schedule  Item  Data 

R.2.3. 1.1 

Display  multiple 
projects  on  one 
schedule  item 
timeline 

The  CAT  system  shall  be 
capable  of  displaying 
multiple  projects  on  one 
schedule  item  timeline. 

F.2. 2.2.4. 1 

Display  Division  Schedule  Item  Timeline 

F.2.2.5.6 

Display  BH  Timeline 

F.2.2.5.6.1 

Display  Branch  Schedule  Item  Timeline 

F.2.2.8.6 

Display  PM  Timeline 

R.2.3. 2 

Display  list  of 
schedule  item  dates 

The  CAT  system  shall  be 
capable  of  displaying  a 
list  of  schedule  item 
dates. 

F.2.2.8.5 

Display  PM  Project  Deliverable  Table 

F.2.3.2.1.7 

Compile  Schedule  Item  Data 

R.2.3. 3 

Display  list  of 
schedule  item 

names 

The  CAT  system  shall  be 
capable  of  displaying  a 
list  of  schedule  item 

names. 

F.2.2.2.4.1 

Display  Division  Schedule  Item  Timeline 

F.2.2.5.6 

Display  BH  Timeline 

F.2.2.5.6.1 

Display  Branch  Schedule  Item  Timeline 

F.2.2.8.6 

Display  PM  Timeline 

R.2.3. 4 

Display  schedule 
item  descriptions 

The  CAT  system  shall  be 
capable  of  displaying 
schedule  item 
descriptions. 

F.2.2.2.4.2 

Display  Division  Schedule  Item  Table 

F.2.2.5.6. 2 

Display  Branch  Schedule  Item  Table 

R.2.3. 5 

Display  schedule 
item  types 

The  CAT  system  shall  be 
capable  of  displaying 

F.2.2.2.4.1 

Display  Division  Schedule  Item  Timeline 

F.2.2.2.4.2 

Display  Division  Schedule  Item  Table 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

schedule  item  types. 

F.2.2.5.6.1 

Display  Branch  Schedule  Item  Timeline 

F.2.2.5.6.2 

Display  Branch  Schedule  Item  Table 

F.2.3.2.1.7 

Compile  Schedule  Item  Data 

F.2.3.2.4 

Calculate  Schedule  Item  Information  for 
Display 

R.2.3.6 

Display  schedule 
item  durations 

The  CAT  system  shall  be 
capable  of  displaying 
schedule  item  durations. 

F.2.2.2.4 

Display  Division  Schedule  Items 

F.2. 2.2.4. 1 

Display  Division  Schedule  Item  Timeline 

F.2.2.2.4.2 

Display  Division  Schedule  Item  Table 

F.2.2.5.6.1 

Display  Branch  Schedule  Item  Timeline 

F.2.2.5.6.2 

Display  Branch  Schedule  Item  Table 

F.2.3.2.4 

Calculate  Schedule  Item  Information  for 
Display 

R.2.3.7 

Display  schedule 
item  notes 

The  CAT  system  shall  be 
capable  of  displaying  a 
schedule  item  note 
associated  to  a  project. 

F.2.2.2.4 

Display  Division  Schedule  Items 

F.2.2.2.4. 1 

Display  Division  Schedule  Item  Timeline 

F.2.2.2.4.2 

Display  Division  Schedule  Item  Table 

F.2.2.2.4.3 

Display  DH  Schedule  Item  Filter  Options 

F.2.2.5.6.1 

Display  Branch  Schedule  Item  Timeline 

F.2.2.5.6.2 

Display  Branch  Schedule  Item  Table 

F.2.2.5.6.3 

Display  BH  Schedule  Item  Filter  Options 

R.2.3.8 

Display  schedule 
item  alerts 

The  CAT  system  shall  be 
capable  of  displaying 
schedule  item  alerts. 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.2.1.6 

Provide  Schedule  Item  Alerts 

F.2. 3.2. 1.6.1 

Accept  Alert  Type  Selection 

F.2. 3.2. 1.6.2 

Provide  New  Date  Alert 

F.2. 3.2. 1.6.3 

Provide  New  Schedule  Item  Alert 

R.2.3.8.1 

Display  alert  when 

When  a  schedule  item  is 

F.2.2.5.7 

Display  BH  GUI  Support  Features 
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[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

schedule  item  is 
upcoming 

upcoming,  the  CAT 
system  shall  be  capable 
of  displaying  an  alert. 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R.2.3.8.2 

Display  alert  when 
a  schedule  item  is 
past  due 

When  a  schedule  item  is 
past  due,  the  CAT  system 
shall  be  capable  of 
displaying  an  alert. 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R.2.3.8.3 

Display  alert  when 
a  schedule  item  is 
complete 

When  a  schedule  item  is 
complete,  the  CAT 
system  shall  be  capable 
of  displaying  an  alert  to 
the  PM 

F.2.2.2.6 

Display  SL  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

R.3 

Project  Funding 
Requirements 

UC.BFM.l 

View  and  Edit  Funding  Status  Sheets 

UC.PM&BH&SL.4 

View  Expenditure  Plans 

UC.PM&BH&SL.5 

View  Funding  Expiration  Dates 

UC.PM&BH&SL.6 

View  Planned  Versus  Actual  Expenditures 

UC.PM.2 

Create  Expenditure  Plan 

R.3.1 

Funding  Inputs 

R.3. 1.1 

Accept  uploaded 
funding  files 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  an  uploaded 
funding  file. 

F.4.6 

Provide  File  Upload  Functionality 

F.4.6.1 

Accept  ZRQS  Files 

F.4.6.2 

Accept  NISE  Files 

F.4.6. 3 

Accept  CN41  Files 

F.4.6.4 

Accept  CDASS  Files 

R.3.1. 1.1 

Accept  ZRQIS  file 
formats 

The  CAT  system  shall  be 
capable  of  accepting 
ZRQIS  file  formats. 

F.4.6.1 

Accept  ZRQS  Files 
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[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.3.1.1.2 

Accept  CN41  file 
formats 

The  CAT  system  shall  be 
capable  of  accepting 

CN4 1  file  formats. 

F.4.6.3 

Accept  CN41  Files 

R.3.1.1.3 

Accept  NISE  file 
formats 

The  CAT  system  shall  be 
capable  of  accepting 

NISE  file  formats. 

F.4.6.2 

Accept  NISE  Files 

R.3.1.1.4 

Accept  CD  ASS  file 
formats 

The  CAT  system  shall  be 
capable  of  accepting 
CDASS  file  formats. 

F.4.6.4 

Accept  CDASS  Files 

R.3.1.2 

Create  a  spend  plan 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  to  create  a  spend 
plan  associated  with  a 
project. 

F.2.2.8.8 

Display  Spend  Plan  Input  View 

F.2.2.8.8.3 

Provide  for  Spend  Plan  Date  Range  Input 

F.2.2.10.1 

Accept  Spend  Plan  Inputs 

F.2.2.10.1.1.4 

Assign  as  Training 

F.2.2.10.1. 6 

Accept  Date  Range  of  Use 

F.2.2.10.1. 7 

Accept  Cost  Estimate 

F.2.3.3.5.2 

Retrieve  Spend  Plan  Data 

F.2.3.3.10 

Associate  Spend  Plans  with  Project 

F.2.4.3.1.5 

Edit  Assigned  Hourly  Cost 

R.3. 1.2.1 

Assign  funding  to 
personnel  labor  per 
project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  to  personnel 
labor  per  project. 

F.2.3. 1.1.11 

Gather  Utilization  Data  for  Specified  Users 

F.2.3.1.2 

Accept  People  to  Project  Assignment  Data 
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Traced  to 

Number 

Name 

Description 

Number 

Name 

R.3. 1.2.2 

Assign  funding  to 
personnel  travel  per 
project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  to  personnel 
travel  per  project. 

F.2.2.10.1.1.3 

Assign  as  Travel 

R.3.1.2.3 

Assign  funding  to 
materials  required 
per  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  to  materials 
required  per  project. 

F.2.2.8.8.1 

Provide  for  Cost  Type  Input  Options 

F.2.2.10.1.1.2 

Assign  as  Materiel 

R.3.1.2.4 

Assign  funding  to 
specific  accounts 
per  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  to  specific 
accounts  per  project. 

F.2.2.8.8.1 

Provide  for  Cost  Type  Input  Options 

F.2.2.8.8.2 

Provide  for  Cost  Input  Name  Assignment 

F.2.2.8.8.5 

Provide  for  Cost  Amount  Input 

F.2. 2. 10.1.1 

Accept  Cost  Input  Type  Assignments 

F.2.2.10.1.2 

Accept  Cost  Input  Name  Assignment 

R.3.1.2.5 

Assign  funding 
CONS  per  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  CONS  per 
project. 

F.2.2.8.8.1 

Provide  for  Cost  Type  Input  Options 

F.2.2.8.8.5 

Provide  for  Cost  Amount  Input 

F.2. 2. 10.1.1 

Accept  Cost  Input  Type  Assignments 

F.2.2.10.1.2 

Accept  Cost  Input  Name  Assignment 

R.3.1.2.6 

Assign  funding 
expiration  dates 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  an 
expiration  date  to  funds. 

F.2.2.8.8.4 

Provide  for  Cost  Date  Range  of  Use  Input 

F.2.2. 14.3. 1.8 

Display  Edit  Options  for  All  Funding 

Aspects 

R.3. 1.2.7 

Assign  funding  note 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
funding  note  to  a  project. 

F.2. 2. 14.3.2 

Display  Options  to  Add  Notes  to  Funding 
Sheets 
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Traced  to 

Number 

Name 

Description 

Number 

Name 

R.3. 1.2.8 

Filter  funding  data 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  filtering  funding 
data. 

F.2.2. 14.3. 1.7 

Filtering  and  Sort  of  All  Funding  Aspects 

R.3.1.2.9 

Assign  funding  to 
custom  items 

The  CAT  System  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  to  a  user  custom 
cost. 

F.2.2.10.1.1.5 

Assign  as  “Custom”  Cost 

R.3. 1.2.10 

Assign  Cost  Type 
as  Fixed  or  Variable 

The  CAT  System  shall  be 
capable  of  accepting  the 
input  of  assigning  a  cost 
type  as  fixed  or  variable. 

F.2.2. 10.1. 3 

Determine  Fixed  or  Variable  Cost 

F.2.2. 10.1. 5 

Accept  Variable  Rate  Cost 

R.3.1.2.1 1 

Assign  funding  to 
training  per  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning 
funding  to  personnel 
Training  per  project. 

F.2.2. 10.1. 1.4 

Assign  as  Training 

R.3.1.3 

Approve  spend  plan 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  to  approve  a  spend 
plan  associated  with  a 
project. 

F.2.2.5.5.4 

Provide  Approval/Disapproval  Display 

F.2.2.5.5.5 

Send  Schedule  Item  Inputs  to  Approval 
Authority 

F.2.2. 8. 8. 6 

Compile  &  Send  Data  for  Project 

Association 

F.2.2. 10.1 

Accept  Spend  Plan  Inputs 

F.2.2. 10.1. 7 

Accept  Cost  Estimate 

R.3.1.4 

Accept  ERP  data 
inputs 

The  CAT  system  shall  be 
capable  of  automatically 

F.2.3.3.2 

Request  Current  ERP  Data  for  User’s  Branch 

Ill 


Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

accepting  actual 
expenditure  inputs  from 
ERP  on  a  weekly  basis. 

F.4.5.1 

Retrieve  and  Save  Data  From  ERP  Every 
Week 

R.3.2 

Funding  Functional 
Requirements 

R.3.2.1 

Organize  funding 
data 

The  CAT  system  shall  be 
capable  of  organizing 
funding  data. 

F.2.2. 14.3. 1.7 

Filtering  and  Sort  of  All  Funding  Aspects 

R.3.2. 1.1 

Sort  data  by 
funding  type 

The  CAT  system  shall  be 
capable  of  sorting  data  by 
funding  type. 

F.2.2. 14.3. 1.7 

Filtering  and  Sort  of  All  Funding  Aspects 

R.3.2. 1.2 

Sort  data  by 
funding  expiration 
date 

The  CAT  system  shall  be 
capable  of  sorting  data  by 
funding  expiration  dates. 

F.2.2. 14.3. 1.7 

Filtering  and  Sort  of  All  Funding  Aspects 

R.3.2.1. 3 

Sort  data  by  CON 
balance 

The  CAT  system  shall  be 
capable  of  sorting  data  by 
CON  balance. 

F.2.2. 14.3. 1.7 

Filtering  and  Sort  of  All  Funding  Aspects 

R.3.2. 1.4 

Filter  funding  data 

The  CAT  system  shall  be 
capable  of  providing 
funding  filter  capability. 

F.2.2. 14.3. 1.7 

Filtering  and  Sort  of  All  Funding  Aspects 

R.3.2. 2 

Calculate  current 
expenditures 

The  CAT  system  shall  be 
capable  of  calculating 
current  expenditures. 

F.2.3.3 

Provide  Funding  Tracking  Functions 

F.2.3.3.5 

Calculate  Funding  Curves 

R.3.2. 3 

Calculate 
expenditure  burn 
rates 

The  CAT  system  shall  be 
capable  of  calculating 
expenditure  burn  rates. 

F.2.3.3 

Provide  Funding  Tracking  Functions 

F.2.3.3.5 

Calculate  Funding  Curves 

F.2.3.3. 12.2.1 

Calculation  of  Over/Underspending 

R.3.2. 4 

Calculate  when 

The  CAT  system  shall  be 

F.2.3.3 

Provide  Funding  Tracking  Functions 
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Description 

Number 

Name 

expenditures  arc 
expected  to  be 
exhausted 

capable  of  calculating 
when  expenditures  are 
expected  to  be  exhausted. 

F.2.3.3.5 

Calculate  Funding  Curves 

R.3.2.5 

Calculate  over/ 
under  spending 

The  CAT  system  shall  be 
capable  of  calculating  the 
amount  of  over/under 
spending. 

F.2.3.3 

Provide  Funding  Tracking  Functions 

F.2.3.3.5 

Calculate  Funding  Curves 

F.2.3.3. 12.2.1 

Calculation  of  Over/Underspending 

R.3.2.6 

Combine  ZRQIS 
and  CN4 1  reports 

The  CAT  system  shall  be 
capable  of  combining 
ZRQIS  and  CN41 
reports. 

F.2.3. 3.2.1 

Request  ZRQIS  Report  From  Data 
Management  Module 

F.2.3. 3.2.2 

Request  CN41  Report  From  Data 

Management  Module 

F.2.3. 3.2. 3 

Combine  ZRQIS  and  CN4 1  Data  Into  Single 
Report 

F.4.6.3 

Accept  CN41  Files 

R.3.3 

Funding  Outputs 

R.3.3.1 

Display  spend  plan 

The  CAT  system  shall  be 
capable  of  displaying  a 
spend  plan  associated 
with  a  project. 

F.2.2.8.2.3 

Display  Spend  Plan  Data 

F.2.2.8.3.5.4 

Display  Labor  Rates 

F.2.2.10.1.1.1 

Assign  Resource  Type 

F.2.2.10.1.4 

Accept  Fixed  Cost 

F.2.3.3.5. 2 

Retrieve  Spend  Plan  Data 

F.2.3.3. 12.2.1 

Calculation  of  Over/Underspending 

R.3.3. 2 

Display  funding 
graphs 

The  CAT  system  shall  be 
capable  of  displaying 
funding  graphs. 

F.2.2.5.5 

Display  BH  Funding  Graph 

F.2. 2.5.5. 1 

Accept  Branch  Head  Request  for  Funding 
Rollup  or  Projects  Specific  Funding  Graph 

F.2.2.5.5. 2 

Display  Branch  Rollup  Funding  Graph 

F.2.2.5.5. 3 

Display  Selected  Project  Funding  Graph 

F.2.2.8.2 

Display  PM  Funding  Graph 

F.2.2.8.2.1 

Display  Funding  Zeroing  Date 

F.2.2.8.2. 5 

Display  Funded  Amount 
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[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.2.8.2.6 

Display  Cost  Projection  Curve 

F.2.2.8.3.5 

Display  Labor  Estimate 

F.2.3.3.4 

For  Requisite  Projects: 

F.2.3. 3.5.1 

For  Each  Project 

F.2.3. 3.5.4 

Create  Actual  Spending  Curve 

F.2.3. 3.6 

Is  user  a  Branch  Fiead? 

F.2.3. 3.7 

Aggregate  Funding  Curves  on  a  Branch 

Level 

F.2.3. 3. 8 

Is  user  Senior  Leadership? 

F.2.3. 3.9 

Aggregate  Funding  Curves  on  a  Competency 
Level 

F.2.3. 3. 12.2.1 

Calculation  of  Over/Underspending 

R.3.3.2.1 

Display  “planned  vs 
expended”  data 

The  CAT  system  shall  be 
capable  of  displaying 
planned  vs.  expended 
data  on  funding  graphs 

F.2.2.8.2.3 

Display  Spend  Plan  Data 

F.2.2.8.2.4 

Display  Fiistorical  Spending  Curve 

F.2.2.8.3 

Display  PM  Funding  Status  Table 

F.2.3. 3.1 

Request  Historical  Funding  Data  for  User’s 
Branch 

F.2.3. 3.5. 3 

Create  Planned  Spending  Curve 

R.3.3.2.2 

Display  calculated 
burn  rates 

The  CAT  system  shall  be 
capable  of  displaying 
calculated  burn  rates  on 
funding  graphs. 

F.2.2.8.2.4 

Display  Historical  Spending  Curve 

F.2.2.8.2.7 

Display  Burn  Rates 
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Traced  to 
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Name 

Description 

Number 

Name 

R.3.3.2.3 

Display  under/over 
expenditure 
according  to  user 
specified  value 

When  displaying  the 
funding  graph,  the 

CAT  System  shall  be 
capable  of  displaying  the 
user  specified  percent 
above  or  below  the 
planned  expenditure  for 
the  current  date. 

F.2.3.3.12.1 

Retrieve  User  Specified  Over/Under 

Spending  Values 

R.3.3.2.4 

Display  Division 
Funding 

The  CAT  System  shall  be 
capable  of  displaying 
division  funding  data  on 
the  Division  Funding 

Graph  on  the  Division 
Fiead  View 

F.2.2.2.2 

Display  Division  Funding  Graph 

R.3.3.3 

Display  funding 
Longsheets 

The  CAT  system  shall  be 
capable  of  displaying 
funding  Longsheets. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

F.2.2. 14.3. 1.1 

Select  Funding  Sheet  to  Display 

F.2.2. 14.3. 1.2 

Display  852  Long  Sheet 

F.2.2. 14.3. 1.3 

Display  CIP  Long  Sheet 

F.2.2. 14.3. 1.4 

Display  Expired  Funds  Long  Sheet 

F.2.2. 14.3. 1.5 

Display  219  Projects  Long  Sheet 

F.2.2. 14.3. 1.6 

Display  Projects  Long  Sheet 

F.2.2. 14.3.4 

Display  Options  to  Sort  by  All  Data  Items  in 
Longsheet 

F.2.3.3.3 

Perform  Long  Sheet  Functions 

F.2.3.3.3.1 

Compile  Data  for  Long  Sheet 

F.2.3.3.3. 1.1 

Request  Long  Sheet  Data  Compilation 
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Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.3.3.3.1.2 

For  Each  Project  In  Branch 

F.2.3.3.3.1.3 

Does  Project  Have  a  CON  Associated  with 

It? 

F.2.3.3.3.1.4 

Retrieve  Associated  CON 

F.2.3.3.3.1.5 

For  Each  Project  in  Branch  Retrieve: 

F.2.3.3.3.1.6 

Associated  Code 

F.2.3.3.3.1.7 

Associated  TPOC 

F.2.3.3.3.1.8 

Associated  Document  Number 

F.2.3.3.3.1.9 

Associated  Project  Number 

F.2.3.3.3.1.10 

Funded  Amount 

F.2.3.3.3. 1.11 

Planned  Amount 

F.2.3.3.3.1.12 

Committed  Amount 

F.2.3.3.3. 1.13 

Obligated  Amount 

F.2.3.3.3. 1.14 

Expensed  Amount 

F.2.3.3.3. 1.15 

Associated  Balance 

F.2.3.3.3. 1.16 

Associated  WBS  Balance 

F.2.3.3.3. 1.17 

WSD 

F.2.3.3.3. 1.18 

WCD 

F.2.3.3.3. 1.19 

Project  Name 

F.2.3.3.3. 1.20 

Fiscal  Year 

F.2.3.3.3. 1.21 

APPN 

F.2.3.3.3. 1.22 

PE/BLI 

F.2.3.3.3. 1.23 

PU/OSIP 

F.2.3.3.3. 1.24 

Sponsor 

F.2.3.3.3. 1.26 

Request  Association  (from  user  via  GUI) 

R.3.3.3.1 

Display  expended 

The  CAT  system  shall  be 

F.2.2.8.2.2 

Display  Projected  Over/Under  Expenditure 

182 


Req 

[uirements 

Traced  to 
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Number 
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funding  for  each 
chargeable  object 

capable  of  displaying 
expended  funding  for 
each  chargeable  object. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.3.2 

Display  current 
balance  of  each 
chargeable  object 

The  CAT  system  shall  be 
capable  of  displaying  the 
current  balance  of  each 
chargeable  object. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.3.3 

Display  allowable 
funding 

The  CAT  system  shall  be 
capable  of  displaying  a 
list  of  allowable  funding. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.3.4 

Display  a  list  of 
available  funding 

The  CAT  system  shall  be 
capable  of  displaying  a 
list  of  available  funding. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.4 

Display  CONS 
associated  to 
projects 

The  CAT  system  shall  be 
capable  of  displaying 
CONS  associated  to 
projects. 

F.2.2.8.3.1 

Display  CON  Name 

F.2.2.8.3.2 

Display  CON  Balance 

F.2.2.8.3.3 

Display  CON  Expenditures 

F.2.2.8.3.4 

Display  CON  Expiration  Date 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

F.2.3.3.3.1.27 

Associate  CONs  with  Project 

R.3.3.5 

Display  funding 
associated  to  date  of 
expiration 

The  CAT  system  shall  be 
capable  of  displaying 
funding  associated  to  date 
of  expiration. 

F.2.2.8.8.4 

Provide  for  Cost  Date  Range  of  Use  Input 

F.2. 2. 14.3.1 

Display  Funding  Sheets 
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Number 

Name 

R.3.3.6 

Display  funding 
associated  with 
funding  type 

The  CAT  system  shall  be 
capable  of  displaying 
funding  associated  with 
funding  type. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.7 

Display  funding 
fiscal  years 
associated  with 
projects 

The  CAT  system  shall  be 
capable  of  displaying 
funding  fiscal  years 
associated  with  projects. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.8 

Display  funding 
fiscal  years 
associated  with 
types  of  funding 

The  CAT  system  shall  be 
capable  of  displaying 
funding  fiscal  years 
associated  with  types  of 
funding. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

R.3.3.9 

Display  an 
uploaded  funding 
file 

The  CAT  system  shall  be 
capable  of  displaying  an 
uploaded  funding  file. 

F.2. 2. 14.3.3 

Display  Options  to  View  Uploaded  Funding 
Files 

F.4.6.1 

Accept  ZRQS  Files 

F.4.6.2 

Accept  NISE  Files 

F.4.6.3 

Accept  CN41  Files 

F.4.6.4 

Accept  CDASS  Files 

R.3.3.9.1 

Display  ZRQIS  file 
formats 

The  CAT  system  shall  be 
capable  of  displaying 
ZRQIS  file  formats. 

F.2.3. 3.2.3 

Combine  ZRQIS  and  CN4 1  Data  Into  Single 
Report 

F.4.6.1 

Accept  ZRQS  Files 

R.3.3.9.2 

Display  CN41  file 
formats 

The  CAT  system  shall  be 
capable  of  displaying 

CN41  file  formats. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

F.2.3. 3.2.2 

Request  CN41  Report  From  Data 

Management  Module 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.3.3.2.3 

Combine  ZRQIS  and  CN41  Data  Into  Single 
Report 

F.4.6.3 

Accept  CN41  Files 

R.3.3.9.3 

Display  NISE  file 
formats 

The  CAT  system  shall  be 
capable  of  displaying 

NISE  file  formats. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

F.4.6.2 

Accept  NISE  Files 

R.3.3.9.4 

Display  CDASS  file 
formats 

The  CAT  system  shall  be 
capable  of  displaying 
CDASS  file  formats. 

F.2. 2. 14.3.1 

Display  Funding  Sheets 

F.4.6.4 

Accept  CDASS  Files 

R.3.3.10 

Display  funding 
note 

The  CAT  system  shall  be 
capable  of  displaying  a 
funding  note  associated  to 
a  project. 

F.2. 2. 14.3.2 

Display  Options  to  Add  Notes  to  Funding 
Sheets 

F.2.2.16.1 

Accept  BFM  Input  Data 

F.2.3.3.3.1.25 

Notes 

F.2.3.3.11 

Associate  BFM  Notes  to  Project  Data 

R.3.3.11 

Display  funding 
alerts 

The  CAT  system  shall  be 
capable  of  displaying 
funding  alerts. 

F.2.2.2.6 

Display  SF  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.3.12 

Provide  Funding  Alerts 

R.3.3.11.1 

Display  alert  when 
there  is  an  over 
budget  condition 

When  there  is  an  over 
budget  condition,  the 

CAT  system  shall  be 
capable  of  displaying  an 
alert. 

F.2.2.2.6 

Display  SF  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.2.2 

Display  Projected  Over/Under  Expenditure 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.3.12 

Provide  Funding  Alerts 

F.2.3.3.12.2 

Calculate  Over/Under  Spending 

F.2.3.3.12.3 

Provide  Funding  Alerts 

R.3.3.11. 2 

Display  alert  when 
there  is  an  under 
budget  condition 

When  there  is  an  under 
budget  condition,  the 

CAT  system  shall  be 
capable  of  displaying  an 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.2.2 

Display  Projected  Over/Under  Expenditure 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.3.12 

Provide  Funding  Alerts 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

alert. 

F.2.3.3.12.2 

Calculate  Over/Under  Spending 

F.2.3.3.12.3 

Provide  Funding  Alerts 

R.3.3.11.3 

Display  alert  when 
project  is  projected 
to  result  in  zero / 
negative  funding 

When  a  project  is 
projected  to  result  in  zero 
or  negative  funding,  the 
CAT  system  shall  be 
capable  of  displaying  an 
alert. 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.3.12 

Provide  Funding  Alerts 

F.2.3.3.12.2 

Calculate  Over/Under  Spending 

F.2.3.3.12.3 

Provide  Funding  Alerts 

R.3.3.11.4 

Display  alert  when 
projected  project 
burndown  rate  is 
off-track 

When  a  projected  project 
burndown  rate  is  off-track 
by  10%  or  greater,  the 

CAT  system  shall  be 
capable  of  displaying  an 
alert. 

F.2.2.5.7 

Display  BF1  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.3.12 

Provide  Funding  Alerts 

F.2.3.3.12.2 

Calculate  Over/Under  Spending 

F.2.3.3.12.3 

Provide  Funding  Alerts 

R.4 

People  to  Project 
Requirements 

UC.BH&SL.l 

View  Personnel  Utilization 

UC.BH.l 

Assign  Personnel  to  Projects 

UC.SL.l 

View  Competency  Manning  Levels 

R.4.1 

People  to  Project 
Inputs 

R.4. 1.1 

Assign  a  person’s 
name  to  a  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
person’ s  name  to  a 
project. 

Worker  Name 

F.2.2.5.3.2.5 

Provide  New  Worker  Option 

F.2.3.1. 1.11.4 

Determine  Project  Assignments 

F.2.3.1.2 

Accept  People  to  Project  Assignment  Data 

F.2.3.1.3 

Associate  Personnel  to  Project 

F.2.3.1.5 

Associate  Project  to  Personnel 

F.2.3.1.7 

Perform  Ghost  Worker  Assignment 

Functions 

F.2.3.6 

Store  Project  to  Personnel  Correlation 

F.2.4.3.1.1 

Edit  User  Name 

F.2.4.3.1.4 

Edit  Assigned  Projects 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.4.1.2 

Assign  a  person’s 
competency 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
person's  competency  to  a 
person's  name. 

F.2.2.5.3.2.5 

Provide  New  Worker  Option 

F.2.4.3.1 

Manage  User  Assignments 

F.2.4.3.1.3 

Edit  Assigned  Competencies 

R.4.1.3 

Assign  a  rate/grade 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a  rate/ 
grade  to  a  person’+C510s 
name. 

F.2.4.3.1. 6 

Edit  User  Rate/Grade 

R.4.1.5 

Assign  the  level  of 
effort 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  the 
level  of  effort  required  by 
each  person  assigned  to  a 
project. 

Percent  Allocation  Worker  Assigned  to  Date 
Range  for  Specified  Project 

F.2.3.1. 1.1 1 

Gather  Utilization  Data  for  Specified  Users 

F.2.3.1. 1.11.8 

Determine  Utilization  Level 

F.2.3.1. 1.11.9 

Compile  Utilization  Data 

F.2.3.1.2 

Accept  People  to  Project  Assignment  Data 

R.4.1.6 

Assign  personnel 
note 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a 
personnel  note  to  a 
project. 

F.2.2.5.3.2.5 

Provide  New  Worker  Option 

F.2.4.3 

Change  User  Profile 

F.2.4.3.1. 7 

Edit  Note  Space 

F.2.4.4 

Save  User  Profile 

R.4.1.7 

Filter  personnel 
data 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  filtering 
personnel  data. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

F.2.2.5.3.2.3.1 

Accept  Sort  Request 

F.2.2.5.3.2.3. 2 

Sort  by  Worker  Name 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.4.1.8 

Ghost  Worker 
Capability 

The  CAT  System  Shall 
be  Capable  of  accepting 
the  input  of  assigning  a 
place  holder  user  to  all 
aspects  of  a  project. 

F.2.2.8.3.5.1 

Display  Ghost  Worker 

R.4.2 

People  to  Project 

Functional 

Requirements 

R.4.2.1 

Organize  personnel 
data 

The  CAT  system  shall  be 
capable  of  organizing 
personnel  data. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

F.2.2.5. 3.2.3. 1 

Accept  Sort  Request 

F.2.2.5.3.2.3. 2 

Sort  by  Worker  Name 

F.2.2.5. 3.2. 3. 4 

Sort  by  Worker  Availability 

R.4.2. 1.1 

Sort  by  % 
utilization 

The  CAT  system  shall  be 
capable  of  sorting  data  by 
%  utilization. 

F.2.2.5.3.2.3 

Provide  Sort  Function 

F.2.2.5. 3.2.3. 3 

Sort  by  Average  Worker  Allocation 

R.4.2. 1.2 

Sort  by  number  of 
personnel 

The  CAT  system  shall  be 
capable  of  sorting  data  by 
number  of  personnel 
assigned  to  a  project. 

F.2.2.5. 3.2.3. 3 

Sort  by  Average  Worker  Allocation 

R.4.2. 2 

Calculate  % 
utilization 

The  CAT  system  shall  be 
capable  of  calculating  % 
utilization  of  personnel. 

F.2.3.1. 1.1 1 

Gather  Utilization  Data  for  Specified  Users 

F.2.3.1. 1.11.8 

Determine  Utilization  Level 

F.2.3.1. 1.11.9 

Compile  Utilization  Data 

R.4.3 

People  to  Project 
Outputs 

R.4.3.1 

Display  personnel 
information 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  information  on 

F.2.2.5. 3. 2. 6 

Trigger  Profile  Manager  Module  Functions 

F.2.2.5. 3. 2.7 

Display  Profile  Manager  Module 

F.2.2.5. 3.2.7. 2 

Display  User  Profile  Information 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

the  profile  manager 
module  residing  within 
the  People  to  Project 
Interface. 

F.2.4 

Manage  User  Profiles 

F.2.4.4 

Save  User  Profile 

R.4.3.1.1 

Display  a  person’s 
name 

The  CAT  system  shall  be 
capable  of  displaying  a 
person’s  name. 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.2.5.3.2.6 

Trigger  Profile  Manager  Module  Functions 

F.2.2.5.3.2.7 

Display  Profile  Manager  Module 

F.2.2.5.3.2.7.2 

Display  User  Profile  Information 

F.2.2.8.3.5.2 

Display  Assigned  Personnel 

F.2.4 

Manage  User  Profiles 

F.2.4.3.1 

Manage  User  Assignments 

F.2.4.4 

Save  User  Profile 

R.4.3.1.2 

Display  a  person’s 
rate/grade 

The  CAT  system  shall  be 
capable  of  displaying  a 
person’ s  rate/grade. 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.2.5.3.2.6 

Trigger  Profile  Manager  Module  Functions 

F.2.2.5.3.2.7 

Display  Profile  Manager  Module 

F.2.2.5.3.2.7.2 

Display  User  Profile  Information 

F.2.4 

Manage  User  Profiles 

F.2.4.3.1 

Manage  User  Assignments 

F.2.4.4 

Save  User  Profile 

R.4.3.1.3 

Display  a  person’s 
competency 

The  CAT  system  shall  be 
capable  of  displaying  a 
person’s  competency. 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.2.5.3.2.6 

Trigger  Profile  Manager  Module  Functions 

F.2.2.5.3.2.7.2 

Display  User  Profile  Information 

F.2.4 

Manage  User  Profiles 

F.2.4.3.1 

Manage  User  Assignments 

F.2.4.4 

Save  User  Profile 

R.4.3.2 

Display  personnel 
associated  to  each 
project 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  to 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

189 


Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

each  project. 

F.2.2.8.3.5.2 

Display  Assigned  Personnel 

F.2.3.1 

Provide  People  to  Project  Tracking  Functions 

F.2.3. 1.1.6 

Determine  Workers  in  Selected  Project 

F.2.3.1. 1.8 

Send  Project  Allocation  View  Data  to  GUI 
Module 

F.2.3.1. 1.9 

Generate  Worker  Detail  Allocation  View 

Data 

F.2.3.1. 1.10 

Send  Worker  Detail  Allocation  View  Data  to 
GUI  Module 

F.2.3. 1.4 

Send  Project  Assignments  to  Project  Data 

F.2.3. 1.6 

Send  Project  Assignments  to  Profile 
Management  Module 

R.4.3.3 

Display  personnel 
associated  to 
amounts  of  funding 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  to 
amounts  of  funding. 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.2.8.3.5.3 

Display  Assigned  Labor  Hours 

R.4.3.4 

Display  personnel 
associated  with  his 
or  her  current 
DAWIA 
certifications 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  with 
his  or  her  current 

DAWIA  certifications. 

F.2.2.2.6 

Display  SL  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R.4.3.5 

Display  required 
date  for  a  person’s 
next  DAWIA 
certification  level 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  and  the 
required  date  for  the  next 
DAWIA  certification 
level. 

F.2.2.2.6 

Display  SL  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R.4.3.6 

Display  personnel 
associated  with  % 
utilization 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  with 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

%  utilization. 

F.2.3.1. 1.2.4 

For  Each  Branch 

F.2.3.1.1.10 

Send  Worker  Detail  Allocation  View  Data  to 
GUI  Module 

F.2.3.1. 1.11.1 

For  all  Workers 

F.2.3.1. 1.11.5 

For  Each  Project  Assignment 

F.2.3.1. 1.11.7 

For  Each  Date  Range 

R.4.3.7 

Display  personnel 
associated  to  level 
of  effort 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  to 
level  of  effort  for  a 
project. 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.3.1. 1.7 

Generate  Project  Allocation  View  Data 

R.4.3.8 

Display  personnel 
associated  with 
availability  for 
tasking 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  with 
availability  for  tasking. 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.2.5.3.2.3.4 

Sort  by  Worker  Availability 

R.4.3.9 

Display  personnel 
associated  with 
duration  of  time 
assigned  to  projects 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  with 
duration  of  time  assigned 
to  projects. 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

F.2.3.1. 1.2.4 

For  Each  Branch 

F.2.3.1. 1.11.5 

For  Each  Project  Assignment 

F.2.3.1. 1.11.7 

For  Each  Date  Range 

R.4.3.10 

Display  personnel 
associated  with 
funding  sponsor 
information 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  associated  with 
funding  sponsor 
information. 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 

R.4.3.11 

Display  a  personnel 
note 

The  CAT  system  shall  be 
capable  of  displaying  a 
personnel  note  associated 
to  a  project. 

F.2.2.5.1 

Retrieve  Branch  Head  People  to  Projects 
Dashboard  View  Data 

F.2.2.5.3.1 

Display  BH  People  to  Project  Interface 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

R.4.3.12 

Display  personnel 
alerts 

The  CAT  system  shall  be 
capable  of  displaying 
personnel  alerts. 

R.4.3.12.1 

Emphasize  an  over- 
utilized  worker 

When  a  person  is  over¬ 
utilized,  the  CAT  system 
shall  be  capable  of 
visually  emphasizing  the 
over  utilization 

F.2.2.5.3.2.2 

Emphasize  Over-allocated  Personnel 

R.4.3.12.2 

Emphasize  an 
under- utilized 
worker 

When  a  person  is  under¬ 
utilized,  the  CAT  system 
shall  be  capable  of 
visually  emphasizing  the 
under  utilization 

F.2.2.5.3.2.1 

Emphasize  Under-allocated  Personnel 

R.4.3.12.3 

Display  alert  when 
a  person’s  DAWIA 
certification 
qualification  is 
coming  due 

When  a  person’s  DAWIA 
certification  qualification 
is  coming  due,  the  CAT 
system  shall  be  capable 
of  displaying  an  alert. 

F.2.2.2.6 

Display  SF  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

R.4.3.13 

Display  People  to 
Projects  GUI 

The  CAT  System  shall  be 
capable  of  displaying  the 
People  to  Project  GUI 

F.2.3.1.1 

Generate  Personnel  Views  Data 

F.2.3. 1.1.3 

Determine  Workers  in  Branch 

F.2.3. 1.1.7 

Generate  Project  Allocation  View  Data 

F.2.3.1.1. 8 

Send  Project  Allocation  View  Data  to  GUI 
Module 

F.2.3.1.1. 11.2 

Request  Historical  Charge  Data  from 

CD  ASS  via  Data  Management  Module 

F.2.3.1.1. 11.3 

Receive  Historical  Charge  Data 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.3.1. 1.11.6 

Determine  Date  Range  Assigned  to  Project 

R.5 

Project  Status  Item 
Reporting 

UC.PM&BH&SL.3 

View  List  of  Obstacles 

UC.PM.l 

Enter  Status  Item  Information 

R.5.1 

Status  Item 

Reporting  Inputs 

R.5. 1.1 

Assign  a  status  item 
to  a  project 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  a  status 
item  to  a  project. 

F.2.2.10.2 

Accept  Schedule  Item  Data  Input 

R.5. 1.2 

Assign  an  Status 

Item  reporting  note 

The  CAT  system  shall  be 
capable  of  accepting  the 
input  of  assigning  an 

Status  Item  reporting  note 
to  a  project. 

F.2.3.4 

Provide  Status  Item  Management  Functions 

F.2.3.4.1 

Enter  New  Status  Item? 

F.2.3.4.2 

Receive  New  Status  Item  Information 

F.2.3.4.3 

Create  Alert  for  New  Status  Item 

R.5.2 

Status  Item 

Reporting 

Functional 

Requirements 

R.5.2.1 

Sort  risks/issues 

The  CAT  system  shall  be 
capable  of  sorting  risks/ 
issues  assigned  to  a 
project. 

F.2.2.8.4 

Display  PM  Obstacles  View 

R.5. 3 

Status  Item 

Reporting  Outputs 

R.5. 3.1 

Display  status 
reports 

The  CAT  system  shall  be 
capable  of  displaying 
status  reports  associated 
to  a  project. 

F.2.2.2.3 

Display  Division  Obstacles  View 

F.2.2.5.4 

Display  Branch  Obstacles  View 

F.2.2.8.4 

Display  PM  Obstacles  View 

F.2.3.4 

Provide  Status  Item  Management  Functions 
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Req 

[uirements 

Traced  to 

Number 

Name 

Description 

Number 

Name 

F.2.3.4.4 

Compile  Data  Status  Item  Information  for 
Display 

F.2. 3.4.4. 1 

Display  Status  Item  Name 

F.2.3.4.4.2 

Display  Status  Item  Status 

F.2.3.4.4.3 

Display  Status  Item  Entry  Date 

R.5.3.2 

Display  Status  Item 
reporting  alerts 

The  CAT  system  shall  be 
capable  of  displaying 

Status  Item  reporting 
“flag”  alerts. 

F.2.2.2.6 

Display  SL  GUI  Support  Features 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.5.7.1 

Display  Alerts 

F.2.2.8.7 

Display  PM  GUI  Support  Features 

F.2.3.3.12.3 

Provide  Funding  Alerts 

F.2.3.4.4. 1 

Display  Status  Item  Name 

F.2.3.4.4.2 

Display  Status  Item  Status 

R.5.3.2.1 

Display  alert  when 
project  is  assigned  a 
status  item 

When  a  project  is 
assigned  a  status  item,  the 
CAT  system  shall  be 
capable  of  displaying  an 
alert. 

F.2.2.5.4 

Display  Branch  Obstacles  View 

F.2.2.5.7 

Display  BH  GUI  Support  Features 

F.2.2.5.7.1 

Display  Alerts 

F.2.3.4 

Provide  Status  Item  Management  Functions 
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APPENDIX  I.  CAT  ACTION  DIAGRAMS 


This  appendix  contains  a  complete  set  of  the  CAT  action  diagrams,  including 
those  that  are  in  Chapter  IV. 
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Operations 


Figure  I- 1.  F.O  Action  Diagram 


Figure  1-2.  F.l  Action  Diagram 
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Figure  1-4.  F.2.1  Action  Diagram 


196 


v'V\ 


\ 


\;:-A 


— > 


.  ^F.2.2.2 

_ ^  Display  Ser  or  . 

Leadership  GUI  . 


Senior 
Lea3|  ship 


im™»\ 


F.2.2.4 


F.2.2.3 

— ►Validate  input— ►  A^2£r  ■; 
I  ^  fromSL  Input  From  GUI ' 


'''^F.2.2.5 

>  Display  BH  , 


User  Type  * 
—  \ 


Pr^ec 
f/ar>^  * 


F.2.2.6  “'-.F.2.2.7 

►Validate  Input — ►  iSHSL 
from  BH  '"hSl 


Display  Project  . 
Manager  GUI 


M5£EE32!W'>i 

►  .wF.2.2.9  \F.2.2.10 

\  Accept  Project 

~ ♦Validate  inpul-^  Manager  Input  r 
from  PM  from  GUI 

■BinmaasHf 


F.2.2.1 1 

^  Display  _ 
Admin  strator 


F.2.2.1 2  \  F.2.2.1 3 

_ *,  ‘ 

from  Administrator 

Administrator  Input  from  GUI 


U  F.2.2.1 5 


Figure  1-5.  F. 2. 2  Action  Diagram 
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Figure  1-6.  F.2.2.2  Action  Diagram 
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Figure  1-7.  F.2.2. 2.4  Action  Diagram 
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Figure  1-8.  F.2.2.5  Action  Diagram 
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Figure  1-9.  F.2.2.5.2  Action  Diagram 
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Figure  I- 10.  F. 2. 3. 2  Action  Diagram 
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Figure  1-11.  F.2.2.5.5  Action  Diagram 
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Figure  1-12.  F.2.2.5.6  Action  Diagram 
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Figure  1-13.  F.2.3  Action  Diagram 
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Figure  1-14.  F.2.3.1  Action  Diagram 
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Figure  1-15.  F.2.3.1  Action  Diagram 
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Figure  1-16.  F.2.3.1.1  Action  Diagram 
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Figure  1-17.  F.2.3. 1.1. 11  Action  Diagram 


206 


F.2.3.2.1 

Accept  Schedule 
Item  Data 

m.ui.w-i.m.w 


F.2.2.5.5.5 

,  Send  Schedule  . 

Item  Inputs  to 
Approval  Authority 


F.2.3.2.3 
J  Retrieve 
Schedue  Item 
Approval 


Schedule 

Item 

Approval 


F. 2.3. 2.4 
Calculate 
Schedule 
Item 


Status 


Figure  1-18.  F.2. 3. 2Action  Diagram 
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Figure  1-19.  F.2.3.2.1  Action  Diagram 
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Figure  1-20.  F.2.3.2. 1 .6  Action  Diagram 
208 


F.2.3.3.1 

•  fc  c  F.2.3.3.2 

* 

Request 

'  Request 

.  Historical 

_ >  Current  ERP  , 

Funding  Data 

Data  for 

for  User's 

A  ‘ 

F.2.3.3.3 

Perform  Long  Sheet 
Functions 


- > 


^ '  '  ^  F  2  3  3  5 
^  F.2.3.3.4  k>  *••*•*•*•* 

O  For  Continue  Calculate  K 
2  Requisite  Funding  Curves 

Projects: 

I  Exit  tmMI-J.tUil 


F.2.3.3.6 
Is  user  a 
Branch 
Head? 


Ve§  w 

r 


F.2.3.3.7  /u 
Aggregate  „ 
Funding  — 1 > 

Curves  on  a 
Branch  Level 
* 


F.2.3.3.8 
Q£  Is  user 
°  Senior 
Leadership?-] 


r 


^  ' 

F.2.3.3.9 
Aggregate 
Funding 
Curves  on  a 
Competency 


V 

F.2.3.3.10 
>  Associate 
Spend  Plans  _ 
with  Project 


F.2.3.3.1 1 
^  Associate  _ 
BFM  Notes  to , 
Project  Data 


'^F.2.3.3.1 2 

_ ^  Provide 

Funding  Alerts 

--ymTxrrnm 


Figure  1-21.  F. 2. 3. 3  Action  Diagram 
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Figure  1-23.  F.2.3.3.3  Action  Diagram 


210 


Figure  1-24.  F. 2. 3. 3. 3.1  Action  Diagram 
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Figure  1-25.  F.2.3.3.5  Action  Diagram 
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Figure  1-26.  F. 2. 3. 3. 10  Action  Diagram 


A 


Project  Level 
Funding  Curve 
Data  for  Display 


Competency  Level  Funding 
Curve  Data  for  Display 


F.2.3.3.12.1 

-4 

Retrieve  User 
•  Specified 

Over/Under 
Spending  Values 

\r 

F.2.3.3.12.2 

Calculate 

Over/Under 

Spending 

■  .UJ.lljjJ.Ud>1 


F. 2.3.3.12.3 

j _ >1 

Provide 

Funding 

Alerts 

r  Branch  Level  Funding  i 
Curve  Data  for  Display  M 


Figure  1-27.  F. 2. 3. 3. 12  Action  Diagram 


Competency 
Level  Funding 
Curve  Data  for 
Display 


r.jyjp 


* 

V 


^F.2.3.3.12.2. 1 


Calculation  of  — 
Over/Underspendin^ 


i 


Over/Underspending 

Data 


Figure  1-1.  F.2.3.3.12.2  Action  Diagram 
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Figure  1-2.  F.2.3.4  Action  Diagram 
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Figure  1-3.  F.2.3.4.4  Action  Diagram 
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Figure  1-4.  F.2.4  Action  Diagram 
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Figure  1-5.  F.2.4.3  Action  Diagram 
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Figure  1-6.  F.2.4.3.1  Action  Diagram 
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Figure  1-7.  F.2.4.3.2  Action  Diagrams 
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Figure  1-8.  F.2.5  Action  Diagram 
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Figure  1-9.  F.3  Action  Diagram 
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Figure  I- 10.  F.4  Action  Diagram 
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Figure  I- 11.  F.4.5  Action  Diagram 
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Figure  1-12.  F.4. 6  Action  Diagram 
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APPENDIX  J.  SCREENSHOTS  OF  SPREADSHEET  MODELING 
FOR  EXAMPLE  PERSONNEL  ALLOCATION  AND  FUNDING 

CALCULATIONS 


f\ 


People  to  Projects  View  Data  and  Worker  Detail  Alloaction  View  Data 

Worker  1  Utilization 


Data  gathered  from 
CAT  Data  Storage. 
These  are  the  workers 
in  a  specified  Branch, 
projects  they  are 


Worker  1 

Utilization 

Begin  Date  End  Date 

Duration 

Project  A 

50.00% 

l-Jan-16 

31-Jan-16 

30 

Project  B 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Project  C 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Worker  2 

Utilization 

Begin  Date  End  Date 

Duration 

Project  A 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Project  B 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Project  D 

100.00% 

l-Jan-16 

31-Jan-16 

30 

Worker  3 

Utilization 

Begin  Date  End  Date 

Duration 

Project  A 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Project  A 

50.00% 

l-Feb-16  28-Feb-16 

27 

Project  B 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Project  C 

25.00% 

l-Jan-16 

31-Jan-16 

30 

Project  A 
Project  B 
Project  C 


12-Nov-lS2-Oee- 1522-Dec-  1511-Jan-1631-Jar>-1620-Feb-iai-Mar- 16 

2seo% 


25.00% 


Project  A 
Project  B 
Project  D 


Worker  2  Utilization 

12-Now- 15  2 -Dec-15  22-Dec-1511-ian-1631-JM>-1620-feb-1611-Mar-16 

25.00% 


100.00% 


Project  A 
Project  A 
Project B 
Project  C 


Worker  3  Utilization 

2-Dec-15  22 -Dec- 15  11 -Jen- 16  31- 

25.00% 


25.00% 

25.00% 


Project  Allocation  View  Data  1 

Worker  1  Worker  2  Worker  3a  Worker  3b 
Project  A  50.00%  25.00%  25.00%  50.00% 

Project  B  25.00%  25.00% 

Project  C  25.00% 

Project  D 


100.00% 


Project  Allegation  View 


Project  A  Raw  Data 

Date  Range  1 

Date  Range  2 

Worker 

l-Jan-16  31-Jan-16 

l-Feb-16  28-Feb-16 

1 

50.00% 

50.00% 

2 

25.00% 

25.00% 

3 

25.00% 

50.00% 

Total 

100.00% 

125.00% 

¥ 


Project  A  Final  Data  (Used  to  Create  Project  Allocation  View) 

Date  Range  1 

Date  Range  2 

Worker  l-Jan-16  31-Jan-16 

l-Feb-16  28-Feb-16 

1  50.0% 

40.0% 

2  25.0% 

20.0% 

3  25.0% 

40.0% 

Figure  J- 1 .  People  to  Project  Calculations 
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Raw  Data  From  CAT's  Date 
Expected  ExpenditurgfSpend  Plan 


Projected  Data: 
CAT  determines 
which 

expenditures 
haven't 
occured,  adds 
under/over 
expenditure 
and  uses  this 
for  remainder 


People 

Name 

Cost 

Date 

Expected 
to  Expend 

Worker  1 

Hof  Hrs 

$1,000.00 

1/3/2016 

Worker  2 

#  of  Hrs 

$1,500.00 

1/15/2016 

Material 

X 

510,000.00 

1/8/2016 

Y 

515,000.00 

1/17/2016 

Travel 

1 

$2,000.00 

1/1/2016 

2 

$4,000.00 

1/18/2016 

Training 

A 

$1,000.00 

1/3/2016 

B 

$1,500.00 

1/5/2016 

Other 

ABC 

S500.00 

1/25/2016 

DEF  B  I  $1,500.00 

1/20/2016 

GHI  $2.000  00 

1/10/2016 

From  ERP  (retrieved  by 
CAT  and  Stored  for 
future  use  as  Historical. 


Cost 

Date 
Expected 
to  Expend 

Planned 

Running 

Total 

$2,000.00 

1/1/2016 

$2,000.00 

$1,000.00 

1/3/2016 

$3,000.00 

$1,000.00 

1/3/2016 

$4,000.00 

$1,500.00 

1/5/2016 

$5,500.00 

$10,000.00 

1/8/2016 

$15,500.00 

$2,000.00 

1/10/2016 

$17,500.00 

$1,500.00 

1/15/2016 

$19,000.00 

$15,000.00 

1/17/2016 

$34,000.00 

$4,000.00 

1/18/2016 

$38,000.00 

$1,500.00 

1/20/2016 

$39,500.00 

$500.00 

1/25/2016 

$40,000.00 

1/31/2016 

$40,000.00 

li 

_ / 

s — 

Planned  Running  Total 


$0.00 

12/27/20 IV1/20161/6/20  lfl/ 1 1/201^16/201^2 1/201^26/201^3 1/201S/V2016 


♦ 


Funding  Recived:  5  Jan  Funding  Graph 


4 


45,000  | 
40,000 
3S.OOO 
30,000 

8 

5  25.000 
|  20.000 
15,000 
10,000 
5.000  j 


$0.00 

1/1/2011/3/20 li/5/20H/7/20H/9/20S?ll/201*13/201Al5/20tfl7/201*19/2016 


Expenditure  Predictions 

Expected 

Funding 

Input  by 

Slope  Calculations: 

Rise  over...  $25,000.00 

Run  16  (today  -  project  start  date) 

slope  =  $1,562.50 

Amount 

40,000 

40,000 

1/1/2016  Project  Start  Date 
1/31/2016 1  Date  to  Expend  By 

Percent  Above/Below  Planned 

jActual  Funding 

amount  above  -$9,000.00  todays  planned  expenditur 

40,000 

1/5/2016 

Date  Received 

Percent  abv/bl  -22.SO* 

40,000 

1/31/2016 

Date  to  Expend  By 

Projected  Funding 

Todays  Date 

|  1/31/2016 1  Project  End  Date  ^ 

Figure  J-2. 


Funding  Graph  Calculations 


224 


APPENDIX  K.  GUI  SCREENSHOTS 


The  following  figures  illustrate  the  final  dashboard  configurations  for  each  user  role  in  CAT.  Dashboards  are  described 
in  more  detail  in  Chapter  V,  Section  C. 


CAT  -  Competency  Administration  Toolset 

BFM  DASHBOARD 
PROJECT  MANAGER  DASHBOARD 
BRANCH  HEAD  DASHBOARD 
SENIOR  LEADERSHIP  DASHBOARD 


Past  Versions: 

CAT  V2.0  (I PR  2) 
CAT  VI  .0  (IPR  1) 


Figure  K-l.  Homepage  Screenshot  from  Prototype  GUI 
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CAT  -  Competency  Administration  Toolset 


BFM  Dashboard  -  Longsheet 
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10SEP20K  10SEP201*.  PROJECT  1 
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Figure  K-2.  BFM  Dashboard  Screenshot 
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Figure  K-3.  Project  Manager  Dashboard  Screenshot 


227 


Figure  K-4.  Project  Manager  Dashboard  Screenshot  -  User  Settings  Window 
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Figure  K-5.  Project  Manager  Dashboard  Screenshot  -  New  Schedule  Item  Window 
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CAT  -  Competency  Administration  Toolset 


Branch  Head  Dashboard  -  Overview 
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Overview  •»  Go 

Create  New  Project 

Status  Update 
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FUNDING  RISK  FY1 

RISK  IN  STAFFING 
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Performance 
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Filter  Out:  Milestones  Deliverables  |  n  Complete  |  Late  |  Go 


Figure  K-6.  Branch  Head  Dashboard  Screenshot 
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Figure  K-7.  Branch  Head  Dashboard  Screenshot  -  User  Settings  Window 
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CAT  -  Competency  Administration  Toolset 


Senior  Leadership  Dashboard  -  Overview 


Generate  Report  Overview 
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Figure  K-8.  Senior  Leadership  Dashboard  Screenshot 


232 


Figure  K-9.  Senior  Leadership  Dashboard  Screenshot  -  User  Settings 
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